Mailinglist Archive: opensuse-buildservice (87 mails)

< Previous Next >
Re: [opensuse-buildservice] Possible mistake with OSC
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Tue, 08 Oct 2019 08:01:37 +0200
  • Message-id: <2346951.IzqmjdAB4T@linux-ywca>
most likely the wrong maling list for this. I answered you via private mail.

On Dienstag, 8. Oktober 2019, 01:56:42 CEST William Brown wrote:
Hi there,

I was recently trying to submit a package update to the internal
SUSE:SLE-15-SP2:GA repo. Because the package had been deleted I was
required to re-branch it, but in the process I forgot to use my internal
alias (iosc) which meant that I accidentally updated to

Now this caused me to have a bit of an anxious moment - had I just leaked
all of SUSE's internal SLE-15-SP2 into the public internet? I'd like to
know if:

A) I have just massively leaked content
B) This mirror is an intentional part of the system

Following on from that, it leads me to an observation, which is that osc is
really hard to get right from a psychology perspective. It's *easy* to make
mistakes or accidentally leak content like this. In this case because I
already had a branch from internal osc, when I re-checked it out the change
in behaviour (a lack of consistency in design terms) caused me to believe I
was still working internally when I was not.

A simple suggestion is that with osc, if you have *multiple* connections in
.config/osc/oscrc, and the current action doesn't "know" which to use,
instead of assuming the default, prompt the user to provide the connection
details or select which one. IE:

# osc branch thing otherthingy

Which instance would you like to do this in?

2) https://internal.obs.instance
[default: 1] #

Second, the presence of the SUSE:SLE-15-SP2:GA if intentional, is also
surprising behaviour - because it meant that a command on the internal
instance also works on the external instance - there is no feedback or
constraint that could stop this. This poses a risk because without the osc
switching as listed above, it could be very easy for someone to have
submitted an MR/SR that would leak vendor or private content to the public

As a result to prevent this another suggestion is that if this *is* a public
mirror of the content, then it should have a different name. This way it
becomes impossible to accidentally submit the MR/SR to the public mirror
because the project does not exist. (This is a constraint in design terms).





William Brown

Senior Software Engineer, 389 Directory Server


Adrian Schroeter <adrian@xxxxxxx>
Build Infrastructure Project Manager

SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
(HRB 247165, AG München), Geschäftsführer: Felix Imendörffer

To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >