On 06. 01. 20 23:41, Peter Jones wrote:
On Mon, Jan 06, 2020 at 02:48:22PM -0500, Robbie Harwood wrote:
If you don't have the time to make a new build once every year, you
shouldn't be a packager, full stop.
I think that's a fair point, but not at all the issue here. I
specifically want not to rebuild this, which is why I *have* rebuilt all
the other packages I own that were earlier on this and similar lists.
[skipping ahead just a little...]
We are talking about crypto-related packages here; being able to
rebuild them and be confident in their contents is arguably more
important than any other kind of package.
I see your point in general, though I don't agree in this case. The
build is reproducible from source with the earlier gnu-efi-devel, we
know exactly what's in it, and (as you know) if there are any serious
issues like a CVE for the OpenSSL build involved which would effect it,
I don't think there's going to be difficulty remaining aware. There's
no reason not to be confident regarding the contents.
That said, the current build issue in this case is my fault, and fairly
trivial, all said and done. I specifically want not to rebuild it - I
very strongly prefer to wait until we're done with the upstream release
and use that instead. There are a couple of reasons for that, and they
overlap significantly with why this shouldn't be part of the mass
rebuilds:
- We literally get nothing out of rebuilding it unless something goes
wrong. Nothing. Aside from some datestamps and the like that are in
this version, you should get the exact same binary. (The next version
will actually be fully debian-style reproducible, but that's assuming
the same compiler, etc.)
- If they're not the same, even if it is merely timestamps in headers
differing, then just rebuilding the two "unsigned" packages without
going through the process to get the third package signed makes our
reproducibility worse, not better.
- Because there aren't enough people participating in the broader
ecosystem (i.e. reviewing other distro's builds to make sure they
haven't messed it up or created a back door, accidentally or on
purpose), getting it signed has the effect of adding hard deadlines
for quite a bit of ancillary work that will require scheduling and
time.
- The worst-case support burden is *extraordinarily* high, in dollars,
and more builds of the same source tree makes it higher in
surprisingly large increments. I can go into detail if you like, but
I think you and many others have heard me explain it several times
before.
- I'm doing most of the upstream work, and doing the rebuilds, getting
them signed, and all the work that comes along with that all take time
away from actually getting the next version out the door, thus making
us farther from the actual desired outcome, rather than closer.
Doing an almost-exactly-the-same rebuild is not merely pointless, it is
actively harmful.
Could you please request an exception for your packages via
https://pagure.io/fesco/issues ? The retirement happens in 2 weeks.
I agree that waiting for the new release now is probably a best course of action
to avoid disruption.
From the long term perspective, I don't think exempting the packages from the
FTBFS policy forever is a good idea:
- The packages were built with an old RPM version, using an outdated
compression method.
- Fedora may introduce new buildroot policies or new compiler features or
flags, and by not rebuilding the package, we never know if something is wrong
regarding that. Having a package that wasn't rebuild for years is a tehcnical
debt in this regard.
- Having a package that fails to build for years prevents us if we ever need
to do an emergency fix.
- While rebuilding the packages might be extremely painful, I think we should
be able to do it at least once a year, as the policy more or less says now.
- Even if you argue that we don't actually want to rebuild the packages just
for the sake of rebuilding them, I argue we should at least make sure we are
able to, even if we only do it via scratchbuilds in
https://koschei.fedoraproject.org/package/shim-unsigned-x64
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
