On Monday, October 31, 2016 1:42:12 PM CET Florian Weimer wrote:
> On 10/26/2016 02:31 PM, Pavel Raiskup wrote:
> > On Wednesday, October 26, 2016 2:03:20 PM CEST Florian Weimer wrote:
> >>> However, extending Koji to support "hidden builds" is certainly a good
> >>> idea.
> >>
> >> Trust me, it's not. Embargoes are against the spirit of Fedora, and a
> >> general hassle for everyone involved.
> >
> > Vague argument, sorry. Please elaborate what's against Fedora.
>
> Looks like I was wrong. I couldn't find an explicit commitment towards
> transparency and openness.
Hms, can't comment this personally.
> Debian has one when it comes to bugs, but Fedora does not.
So how debian treats embargo bugs? As I understood it previously, it
looked like they are able to build in advance, or not? Do they consider
this "open" enough?
Do we consider temporary window before transparentl publishing everything to be
an issue against openness or transparency? To making all of this
acceptable (for me), it requires of course that the package "push" action
is a kind of "atomic":
- builds are published only if CVE is published in the end
- builds are published only if the sources were already published
(immediately before)
- there must be obvious that packer did not build something from crafted
SRPM
> > The "status quo" is bad, our _users_ are the ones who suffer from delays
> > in CVE fixes. We should care take about users, in the first place.
>
> The question is where these delays come from.
>
> If a (allegedly non-critical) Firefox update is delayed by weeks, this
> is certainly not caused by not being able to build embargoed package
> updates for Fedora.
>
> In fact, I strongly suggest that any delay by more than one day is *not*
> caused by lack of embargo support in the Fedora infrastructure because
> the delay added by fedpkg push && fedpkg build rarely amounts to that.
>
> There are certainly security updates which require more time to prepare,
> but those typically require coordination over several packages and
> involve potentially backwards-incompatible changes. This is hardly
> something which is feasible to do under embargo.
Yep, accepted. But we don't have to cover all use cases.
> >> Deploying a lot of infrastructure for the one or two cases per year
> >> where it comes in handy does not make sense.
> >
> > That's more than _two cases_ a year
>
> Could you name a few cases where this would make a difference? If there
> are so many, surely it's easy to come up with a couple of examples.
Starting the list of examples by PostgreSQL, there are several updates a
year (some are security related). Distro packagers are nicely asked to
have a look at the tarballs and perform testing in advance.
> Than we could look at Fedora update delays for those and see to what
> extent building fixed packages in secret, during the embargo period,
> would reduce those delays.
*Full* update delays are usually related to karma++. But once the build
is in 'testing', it is fine from the security POV.
So in the end, the delay is basically between upstream announcement and
(git push; fedpkg build; fedpkg update). It is usually not a huge delay,
because we plan this according to upstream schedule -> but having the
update prepared with full respect to upstream would ease the preparation
phase.
> > Upstream maintainers are *asking us* in advance to report them back
> > whether the release tarball works for us! And they would willingly fix
> > the release tarballs or help us with issues, but we are unable to respond
> > (that's shame). Yeah, I'm able to do my local build on x86_64 machine
> > (and build in i686 mock), but that's everything I can do; if the aarch64
> > fails for me, then we'll have nontrivial delay..
>
> Again, concrete examples here (and not for rebases targeting rawhide),
> would be more convincing.
Personally I can mention only PostgreSQL, there was such upgrade last week
(while I posted my previous message actually). That's not only about
Rawhide (F23+).
> > I'm OK to accept the fact "hidden builds" are not perfect approach, that's
> > right, but that could be relatively easy for implementation.
>
> I haven't tried to implement anything in Koji, so I'm not sure how easy
> it is to get there. There seem to be a lot of corner cases to consider:
> Should fedpkg new-sources uploads default to private? Are all packages
> allowed to see all embargoed builds? Do we need one temporary build
> root per embargoed fix to deal with dependency chains?
IMO: No && s/packages/packagers/ No && Yes.
> These look like difficult decisions, and that's not even about
> implementation at all.
No doubts.. Doesn't sound easy at all, so if there was easier way to solve the
problem?
Pavel
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
