On Friday 21 August 2009 11:56:25 Adrian Schröter wrote:
Am Freitag, 21. August 2009 11:22:52 schrieb Andreas Gruenbacher:
On Friday 21 August 2009 10:18:35 Adrian Schröter wrote: ...
Yes, but when you share these objects, can you avoid that some of them do not become visible ?
Huh? What do you mean?
An example, you have a package kernel-source in project Kernel:HEAD and in openSUSE:11.1:Update:SECRET
Kernel:HEAD is public readable, but the openSUSE:11.1:Update:SECRET project contains a non-public security fix.
The backend should avoid for one to store the data double, so it should share data between both projects.
But it must not be possible to access to change sets of :SECRET project via Kernel:HEAD.
With the native git protocol, this works as follows: the client asks the server to send any missing objects for a list of references (tags or branches), and tells the server which references it knows about (i.e., the objects that the client's local tags and branches point to). The server goes through the requested references and checks which objects are new (by recursively following to the parents of commits until it finds common objects). It then sends all new objects back to the client. If there are no commonalities, it sends all objects reachable from the specified references. I'm not sure if the protocol allows to retrieve a specific commit just from its sha1 checksum. If it does, finding a random commit would still require guessing a basically random 160-bit number, which is sufficiently hard that we won't have to worry about this theoretical possibility. Access over the http protocol might be less secure depending on how the http server is configured: with directory listing enabled, it would be possible to scan for unreferenced objects. This is under our control, though. Andreas -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org