Le vendredi 03 juillet 2020 à 09:48 +0200, Pierre-Yves Chibon a écrit :
> On Thu, Jul 02, 2020 at 12:10:58PM +0200, Björn Persson wrote:
> > Nicolas Mailhot wrote:
> > > The same process that commits a new state of the changelog file
> > > in
> > > sources,
> > > commits the date that was written in the changelog in a separate
> > > key =
> > > value
> > > file (with the components of the build evr, the last packager id,
> > > etc).
> >
> > Do you mean that the key/value file will be committed to Git from
> > inside
> > Koji? Do the Koji builders have write access to Git?
>
> This is the part that worries me a little about this approach.
> Builders currently do not have commit access to git and I'm not sure
> if we want them to considering they have git installed (so they can
> clone) as well as access to all the packages in dist-git from a
> networking point of view (again so they can clone).
> So if we were to give the builders commit access to dist-git, an
> attacker could easily commit to any other packages, potentially from
> something as easy as a scratch-build.
>From a purely architecture POW I’m convinced the proposed approach is
the correct approach. Anything else proposed so far involves:
– tying a low-level event like "build occurred at date XXX" to high-
level Fedora infra (making our workflow non portable and
incompatible with downstreams and third parties)
– taking bets in git that a build will occur and succeed (before it
actually occurs and succeeds, in real life builds fail for various
reasons), and
– attempting to munge spec file behind the packager back (unlikely to
work fine the more automated and dynamic we made those).
However, because it’s the correct architecture solution, it also forces
to make hard architectural choices, instead of mixing unrelated things
in git and pretending that makes the result fine. Mixing unrelated
things in a pile of container or git poo and pretending the result is
fine is exactly what I hate in contenerish build workflows and why I
work on rpm packaging.
>From a pure high-level view, the thing in our infra that gates builds
and decides whether they are official or scratched is bodhi.
So if you want to push Fedora release logic to its ultimate conclusion,
the thing that should be in charge of committing the new
release/changelog build state to package history in git is bodhi, not
koji. And you can put security related checks there, since deciding to
push things to users requires security related checks anyway (that
probably also involves branching while a bodhi update is in flight and
not approved yet).
However, that’s if you want to push the model to its ultimate
conclusion and have something nice solid, automated, and future-proof.
If you don’t want to touch bodhi, and it you do not want koji to commit
to git (which, is not the best of things for the reasons you stated,
and for the reasons I stated), you can just:
– make the koji client return the URL that will contain the SRPM at the
end of the build process if it succeeds.
– have the person of script that called the koji client (and has,
presumably, write access to the corresponding packages) consult the
build results later
– and have this person or script decide if he or it wants to commit the
build result to history or not
That’s the REST way of doing things. It’s a co-out because you push
hard commit decisions to the client, but it’s a prefectly valid
approach. The commit decision exists with or without my change, it’s
just people have (successfully) convinced themselves git is magic and
git makes release decisions go away.
You could also try to filter source files to limit the back commit to
specific files. But really, if you don’t trust your build process to
modify files in a secure way, you should not distribute the produced
RPMs in the first place.
> rpmautospec relies on git tags to store the build info, could it be
> considered here?
As explained above, that does not solve any of the hard problems, that
handwaves them away by pretending that because someone filled some
metadata in git, it corresponds to the actual build state.
Regards,
--
Nicolas Mailhot
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
