Okay, made you the admin of that repo. Have fun, as they say :sweat_smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-2018081307
You are receiving this because you are subscribed to this thread.
Message ID:
Yes, I'll take the ownership for now. Thanks.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-2017947916
You are receiving this because you are subscribed to this thread.
Message ID:
> I'm in favor of an separate project. I'm willing to take maintainership if
> nobody else steps up...
@mlschroe , shall I transfer the ownership of
https://github.com/rpm-software-management/rpmpgp_legacy to you? Otherwise I'll
just archive the thing.
--
Reply to this email directly or view
Closed #2414 as completed via 63e369cd3579114a011d3fd5eafaeafa8b1b2e88.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#event-12183852540
You are receiving this because you are subscribed to this thread.
Message ID:
https://github.com/rpm-software-management/rpm/pull/2984 implements the dummy
PGP option.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-2006529326
You are receiving this because you are subscribed to this thread.
Finally managed to convince myself that it should be feasible (with reasonable
amount of work) to have a "nopgp" build option by adding a dummy implementation
of the internal PGP interface that just returns -ENOTHOME for everything, and
allow choosing between libgcrypt and openssl for the hash
> > @kanavin Are all of the RPMs used also built locally? In that case
> > disabling signature checking is fine.
>
> Yes of course. Yocto is fully self-contained, except for the bootstrap items
> mentioned above. It builds components from source, then makes its own
> packages from the
> @kanavin Are all of the RPMs used also built locally? In that case disabling
> signature checking is fine.
Yes of course. Yocto is fully self-contained, except for the bootstrap items
mentioned above. It builds components from source, then makes its own packages
from the binaries, then makes
The reason for getting rid of the internal OpenPGP parser is that it turns out
to have security vulnerabilities that are exploitable if someone does `gpg2
--export --armor -o s.asc FINGERPRINT && rpmkeys --import s.asc`. Patching
these vulnerabilities isn’t practical, as it would require a
@kanavin Are all of the RPMs used also built locally? In that case disabling
signature checking is fine.
FYI, both rustc and clang are native cross compilers with support for multiple
targets. The same rustc and clang that are used to compile programs for the
build environment can also be
> > Using host distro tools in cross-compilation builds is problematic, as we
> > don't have control over what versions we're going to get, and how they are
> > built and configured. To ensure things work in a reproducible manner, yocto
> > builds its own rpm executable that can run on the
> > > So Yocto can accept that regression in package security, we'll make sure
> > > to place warnings where appropriate.
> >
> >
> > Another option would be to use the host system’s RPM for verifying the
> > packages.
>
> Using host distro tools in cross-compilation builds is problematic, as
> > So Yocto can accept that regression in package security, we'll make sure to
> > place warnings where appropriate.
>
> Another option would be to use the host system’s RPM for verifying the
> packages.
Using host distro tools in cross-compilation builds is problematic, as we don't
have
> > > We can live with rpm verification disabled too.
> >
> >
> > This is a terrible idea from a security perspective.
>
> In embedded linux world, production systems are rarely if ever updated from
> package feeds by a package manager. Rather, the whole root filesystem gets
> overwritten
> > We can live with rpm verification disabled too.
>
> This is a terrible idea from a security perspective.
In embedded linux world, production systems are rarely if ever updated from
package feeds by a package manager. Rather, the whole root filesystem gets
overwritten from an image file.
> So outsourcing the crypto to external gpg executable would be very welcome.
This isn’t going to happen because spawning an external program breaks in too
many situations.
> We can live with rpm verification disabled too.
This is a terrible idea from a security perspective.
--
Reply to this
Just wanted to add the Yocto perspective: we don't have anything against
sequoia, except its build dependencies. It needs both rust and clang (via one
of the crates), rust and cland are both extremely heavy items to build, and we
can't inject them into the core build sequence because it would
The really annoying part about this is that if it wasn't for the stupid
pgpIdentItem() function in librpmio, we could just hide a these two val->string
conversions into a private helpers someplace in librpm. Back when it was added,
pgpIdentItem() was a shortcut to avoid exposing a struct or a
I did some cleanup surrounding this today, managed to remove quite a bit of
related unused cruft that has been just sitting there for twenty years.
We're now annoyingly close to be able to bury the rpmpgpval.h table stuff into
the internal parser too. The only things needing that data now in
I looked at this a bit and properly externalizing seems quite a lot of work
because of two-way dependencies between it and rest of rpm.
I didn't actually try it yet, but I think splitting this into a submodule
rather than a separate project would be far more reasonably achievable.
Thoughts on
Thanks for the explanation.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-1476740667
You are receiving this because you are subscribed to this thread.
Message ID: ___
For now we'll stick with the internal implementation. That doesn't mean we will
never switch to sequoia when it's proven to be mature enough in a year or two.
(Thanks Fedora for beta testing ;-) )
--
Reply to this email directly or view it on GitHub:
@mlschroe : Do you mind sharing your motivation. Does OpenSUSE plan to stick
with the internal OpenPGP implementation?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-1474051989
You are receiving this because you are
I'm in favor of an separate project. I'm willing to take maintainership if
nobody else steps up...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-1473909170
You are receiving this because you are subscribed to this
Nope. Rpm is better off not knowing the damnest thing about OpenPGP format. An
external helper would be considered a stop-gap measure for those
unable/unwilling to use rpm-sequoia for some reason, nothing more.
Another possibility (and these aren't exclusive) is to split the existing
parser to
If RPM goes this route, it should keep a small part of the internal parser.
Specifically, it should keep the checks that the signature is a single OpenPGP
signature packet of the correct type. This is a workaround for a known and
unfixed denial-of-service vulnerability in GnuPG that I
Actually there is a way to have the cake and eat it too: once upon a time, rpm
called an external program (gpg back then) to verify signatures. It could do it
again. It would be slower and there would be other compromises to be made no
doubt, but between no security and slow security...
--
Continuing where #1935 left off: the internal OpenPGP parser has now been
deprecated and declared essentially frozen, but this is a difficult and
cumbersome position to hold for a number of reasons, including hindering other
development work in this area.
We simply can't have Rust as a hard
28 matches
Mail list logo
