On Fri, Jan 22, 2021 at 02:41:52PM +0100, Clement Verna wrote:
On Fri, 22 Jan 2021 at 00:06, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> On Thu, Jan 21, 2021 at 08:04:42PM +0000, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Thu, Jan 21, 2021 at 12:43:35PM +0100, Fabio Valentini wrote:
> > > On Thu, Jan 21, 2021 at 12:39 PM Panu Matilainen
<pmatilai(a)redhat.com>
> wrote:
> > > >
> > > > On 1/21/21 1:27 PM, Fabio Valentini wrote:
> > > > > On Thu, Jan 21, 2021 at 12:22 PM Panu Matilainen <
> pmatilai(a)redhat.com> wrote:
> > > > >>
> > > > >> On 1/21/21 9:56 AM, Florian Weimer wrote:
> > > > >>> With rpm-4.15.1-3.fc32.1.x86_64, I get this error:
> > > > >>>
> > > > >>> $ rpm -qip
>
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everyth...
> > > > >>> error: /var/tmp/rpm-tmp.6iU66n: signature hdr data: BAD,
no. of
> bytes(88084) out of range
> > > > >>> error:
>
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everyth...:
> not an rpm package (or package manifest)
> > > > >>>
> > > > >>> Is this expected?
> > > > >>>
> > > > >>
> > > > >> Certainly not.
> > > > >>
> > > > >>> It seems that rpm-4.16.1.2-1.fc33.x86_64 can parse the
RPM just
> fine.
> > > > >>> But rpm-4.14.3-4.el8.x86_64 does not like it, either.
> > > > >>
> > > > >> Based on a quick random sampling, this would appear to be a
very
> recent
> > > > >> thing, the only affected packages I could find (which
doesn't mean
> > > > >> others couldn't exist) were built in the last few days,
such as
> the
> > > > >> above and these:
> > > > >>
> > > > >>
>
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everyth...
> > > > >>
>
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everyth...
> > > > >>
> > > > >> ...which were all built on Jan 18th. The only recent change
to
> rpm is
> > > > >> the DWARF-5 support but based on changelogs that seems to
have
> landed
> > > > >> the day after, so I dunno.
> > >
> > > (snip)
> > >
> > > > > Is it possible that this was triggered by switching on signed
RPM
> contents?
> > > > > If I understand the implementation correctly, it messes with
the
> RPM headers.
> > > >
> > > > Oh, I wasn't aware the file signing proposal had been approved,
much
> > > > less enabled. I thought I raised "some objections" on the
enablement
> of
> > > > the feature from rpm maintainer perspective.
> > >
> > > It has *not* been approved (yet). Which is why I grumbled about
> > > enabling the signing in production infra during yesterday's FESCo
> > > meeting.
> >
> > Oh, I didn't fully understand your comment at the time. I automatically
> assumed
> > that "enabled in production" only means that the *code* is there,
i.e.
> that
> > the version of rpm has been updated in preparation. Actually enabling
> this
> > while the proposal is being discussed is definitely NOT OK. It makes
> > mockery of the whole Change process and deliberation on fedora-devel and
> > the fesco ticket.
>
> I tried to explain this at the meeting, but I guess I was too terse.
>
> First, let me say that I (and I am pretty sure everyone involved) was
> unaware of the rpm bug. I hope Patrick will chime in, by my
> understanding is that rpm specs said they changed this to 64MB, but the
> commit involved only changed it to 64k. :(
>
> This is unfortunate and I am sorry it happened.
>
> We don't currently have a signing setup in staging that allows testing
> this, and wanting to make sure everything worked we put it in place.
> I did not know that it would cause this issue or I would not have
> allowed it to be deployed. On the other hand, we now know about this
> issue instead of learning about it after the mass rebuild is over.
Sorry, but I disagree with the evaluation that this is OK.
It seems fairly obvious to me that nobody knew about the bug, and it
wouldn't have been enabled if the bug was discovered beforehand. But
even with the absence of known bugs, for complicated changes like
this, there is always a risk of bugs and the potential to disrupt
other people's work. It is better to assume that there will be bugs.
The official package build system is not CI for unapproved projects.
Yes, at some point we need to flip the switch and enable the new thing,
but this should be done *after* being agreed on and announced, not
before, and not silently.
+1 I think we should actually be celebrating the fact that we have
enabled
this early and found a problem before the mass rebuild.
That's the whole point behind continuous integration and getting early
feedback.
Yes, this is one good outcome.
Zbyszek