On Friday 21 August 2009 11:56:25 Adrian Schröter wrote:
Am Freitag, 21. August 2009 11:22:52 schrieb Andreas
On Friday 21 August 2009 10:18:35 Adrian Schröter
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
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
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.
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org