Hi Simo,
On Fri, 14 Oct 2022 18:28:01 +0200,
Simo Sorce wrote:
> At this time, as far as I know, there is no OpenPGP work of any kind on
> supporting PQC algorithms. Furthermore the way we use signatures in RPM
> really has no resemblance to the scenarios OpenPGP was built for.
>
> So we should
On Thu, 2022-12-01 at 00:41 +, Daniel Alley wrote:
>
> * zchunk and deltarpm both reimplement / "bundle" multiple different
> hashing algorithms
zchunk does have bundled versions of various hashing algorithms, but,
if it's compiled against OpenSSL (as it is in Fedora), it uses the
OpenSSL
On Thu, 2022-12-01 at 00:41 +, Daniel Alley wrote:
> I'm quite not sure how one would go about empirically measuring
> something like that - at least in the general case. It might be an
> interesting research topic. So no, unfortunately I don't really have
> hard evidence for this.
We did
I'm quite not sure how one would go about empirically measuring something like
that - at least in the general case. It might be an interesting research
topic. So no, unfortunately I don't really have hard evidence for this.
I just know that of all the C libraries I've looked at, in my personal
Once upon a time, Daniel Alley said:
> 100 C packages with 100 separate copies of sha256.c sitting in their source
> trees (which seems like an entirely realistic comparison)
You keep saying this - do you have any evidence that this is the case?
--
Chris Adams
> I think almost all of these qualify as "Core system libraries that
> pretty much everything depends on.".
> Building their C dependencies from vendored copies (if that is even
> supported) and statically linking them seems like a pretty bad idea in
> almost all cases here, especially for things
On Wed, 2022-11-30 at 18:26 +, Simon Farnsworth via devel wrote:
> On Wednesday, 30 November 2022 17:47:16 GMT Fabio Valentini wrote:
> > On Wed, Nov 30, 2022 at 6:21 PM Daniel Alley wrote:
> > > I feel like there is insufficient recognition of the extent to which C
> > > libraries do
On Wednesday, 30 November 2022 17:47:16 GMT Fabio Valentini wrote:
> On Wed, Nov 30, 2022 at 6:21 PM Daniel Alley wrote:
> > I feel like there is insufficient recognition of the extent to which C
> > libraries do "bundling". Not "bundling" in the sense of vendoring a
> > whole library, but in
On Wed, Nov 30, 2022 at 6:21 PM Daniel Alley wrote:
>
> > Do I really need to explain this point? I think linking against system
> > OpenSSL is *way better* than statically linking to a random vendored
> > copy of it.
>
> There are maybe about 100-120 libraries for which this is obviously the
> Do I really need to explain this point? I think linking against system
> OpenSSL is *way better* than statically linking to a random vendored
> copy of it.
There are maybe about 100-120 libraries for which this is obviously the case.
openssl, glibc, glib2, zlib, libxml2, libcurl, kde
On Wed, 30 Nov 2022 at 07:54, Daniel P. Berrangé
wrote:
> On Wed, Nov 30, 2022 at 11:54:10AM +, Peter Robinson wrote:
> > Hi Fabio,
> >
> > Been meaning to reply to this, but it got lost in the mail pile.
> >
>
> > > > But running `cargo fetch` with a clean cache pulls down *390*
> crates.
On Wed, Nov 30, 2022 at 8:16 AM Fabio Valentini wrote:
>
> On Wed, Nov 30, 2022 at 12:54 PM Peter Robinson wrote:
> >
> > > This is true, and probably also not "fixable". We need to make some
> > > amount of non-upstreamable patches to some crates (most notably,
> > > removing Windows- or mac
On Wed, Nov 30, 2022 at 12:54 PM Peter Robinson wrote:
>
> > This is true, and probably also not "fixable". We need to make some
> > amount of non-upstreamable patches to some crates (most notably,
> > removing Windows- or mac OS-specific dependencies, because we don't
> > want to package those),
On Wed, Nov 30, 2022 at 11:54:10AM +, Peter Robinson wrote:
> Hi Fabio,
>
> Been meaning to reply to this, but it got lost in the mail pile.
>
> > > But running `cargo fetch` with a clean cache pulls down *390* crates. Of
> > > these, it looks like 199 (!) are already packaged as
Hi Fabio,
Been meaning to reply to this, but it got lost in the mail pile.
> > I _very much_ appreciate all the work you and the other Rust SIG folks
> > (Igor and Zbyszek in particular but I'm sure others as well!) have put into
> > packaging rust apps and crates and all of the systems around
On Tue, Nov 01, 2022 at 01:30:01PM -0500, Michel Alexandre Salim wrote:
> I've finally gotten round to doing some polishing and getting it
> packaged:
> - updates for Fedora 36, 37, and Rawhide:
> https://bodhi.fedoraproject.org/updates/?search=rust-update-set-0.0.1=python-rust-update-set
> -
Hi Simo,
On Fri, 14 Oct 2022 22:36:09 +0200,
Neal H. Walfield wrote:
> On Fri, 14 Oct 2022 18:28:01 +0200,
> Simo Sorce wrote:
> > At this time, as far as I know, there is no OpenPGP work of any kind on
> > supporting PQC algorithms.
>
> The German BSI contracted MTG AG to design and implement
Matthew Miller wrote:
> Rust tends to be more fine-grained. I don't think this is necessarily
> rust-specific _really_ — I think it's a trend as people get more used to
> this way of doing things.
And this is inherently a PITA to package, unfortunately.
It is indeed not Rust-specific, other new
On Tue, Nov 1, 2022 at 7:07 PM Demi Marie Obenour wrote:
>
> On 11/1/22 10:40, Matthew Miller wrote:
> > On Wed, Oct 19, 2022 at 01:04:39PM +0200, Fabio Valentini wrote:
> >> For intra-project dependencies (i.e. bevy components depending on
> >> exact versions of bevy components), this is kind of
Hi all,
Just a note that over the summer, our intern did a project to try and
address some of these issues (namely, that while it's trivial to convert
a single crate to an RPM, trying to automate packaging all the
dependencies and making sure that you don't break anything else while
doing so is
On Tue, Nov 1, 2022 at 3:40 PM Matthew Miller wrote:
>
> On Wed, Oct 19, 2022 at 01:04:39PM +0200, Fabio Valentini wrote:
> > I'll respond inline.
>
> Me too -- and apologies for the delay.
>
>
> > > I fundamentally disagree with Kevin on a deep level about "entirely
> > > useless", but ... find
On 11/1/22 10:40, Matthew Miller wrote:
> On Wed, Oct 19, 2022 at 01:04:39PM +0200, Fabio Valentini wrote:
>> I'll respond inline.
>
> Me too -- and apologies for the delay.
>
>
>>> I fundamentally disagree with Kevin on a deep level about "entirely
>>> useless", but ... find myself kind of
On Wed, Oct 19, 2022 at 01:04:39PM +0200, Fabio Valentini wrote:
> I'll respond inline.
Me too -- and apologies for the delay.
> > I fundamentally disagree with Kevin on a deep level about "entirely
> > useless", but ... find myself kind of agreeing about the "unpackagable"
> > part. I mean:
On 10/24/22 23:23, Petr Menšík wrote:
Hi, maybe it was already answered.
Not long ago Thunderbird switched from using installed GPG to its own
implementation inside. I think I have found the library part and it
seems to be in C++, which should be much more easier to integrate than
rust
Hi, maybe it was already answered.
Not long ago Thunderbird switched from using installed GPG to its own
implementation inside. I think I have found the library part and it
seems to be in C++, which should be much more easier to integrate than
rust libraries.
I think the project link is:
On Wed, Oct 19, 2022 at 01:04:39PM +0200, Fabio Valentini wrote:
> On Wed, Oct 19, 2022 at 11:25 AM Matthew Miller
> wrote:
> >
> > I _very much_ appreciate all the work you and the other Rust SIG folks
> > (Igor and Zbyszek in particular but I'm sure others as well!) have put into
[… and Fabio
On 10/20/22 10:01, Neal Gompa wrote:
> On Thu, Oct 20, 2022 at 9:39 AM Kevin Kofler via devel
> wrote:
>> Rust needs to adapt to become relevant in GNU/Linux distributions.
>>
>
> There is nobody pushing for Rust to improve anymore. When Igor and I
> were building out Fedora Rust, we did some
To Neal's point, I had the audacity to suggest some improvements along the
lines of docutils and the response was underwhelming.
https://users.rust-lang.org/t/rust-analog-to-the-python-compilers-docutils/82813?u=blaisep
On Thu, Oct 20, 2022 at 10:02 AM Neal Gompa wrote:
> On Thu, Oct 20, 2022
On 20. 10. 22 14:26, Panu Matilainen wrote:
Which of the following will happen:
1) rpm will gain ExclusiveArch: %{rust_arches}
2) we will stop requiring the above in Rust packages, as Rust is 100% available
3) rpm will %ifarch %{rust_arches} this change
4) something else (what?)
IMHO if we do
On 20. 10. 22 12:11, Fabio Valentini wrote:
Which of the following will happen:
1) rpm will gain ExclusiveArch: %{rust_arches}
2) we will stop requiring the above in Rust packages, as Rust is 100% available
3) rpm will %ifarch %{rust_arches} this change
4) something else (what?)
IMHO if we do
On Thu, Oct 20, 2022 at 9:39 AM Kevin Kofler via devel
wrote:
>
> Matthew Miller wrote:
> > I fundamentally disagree with Kevin on a deep level about "entirely
> > useless", but ... find myself kind of agreeing about the "unpackagable"
> > part. I mean: clearly we've found a way, but I'm really
Matthew Miller wrote:
> I fundamentally disagree with Kevin on a deep level about "entirely
> useless", but ... find myself kind of agreeing about the "unpackagable"
> part. I mean: clearly we've found a way, but I'm really not sure we're
> providing a lot of _value_ in this approach, and I'm also
Peter Robinson wrote:
> Why are they insecure? This is public open data, not banking data,
> where the data being downloaded is verifiable by the rpm signatures
> and signing keys.
The metadata is not, at least not currently.
Kevin Kofler
___
On 10/20/22 12:03, Miro Hrončok wrote:
On 10. 10. 22 16:32, Ben Cotton wrote:
For the last 20 years or so, RPM has used a home-grown OpenPGP parser
for dealing with keys and signatures. That parser is rather infamous
for its limitations and flaws, and especially in recent years has
proven a
Lots of good wisdom here, thank you. IMHO Rust will benefit from whatever
"adult supervision" Fedora can provide.
-Blaise (currently undergoing treatment for injuries sustained supporting
npm in production)
On Wed, Oct 19, 2022 at 7:05 AM Fabio Valentini
wrote:
> On Wed, Oct 19, 2022 at 11:25
On Thu, Oct 20, 2022 at 11:03 AM Miro Hrončok wrote:
>
> On 10. 10. 22 16:32, Ben Cotton wrote:
> > For the last 20 years or so, RPM has used a home-grown OpenPGP parser
> > for dealing with keys and signatures. That parser is rather infamous
> > for its limitations and flaws, and especially in
On 10. 10. 22 16:32, Ben Cotton wrote:
For the last 20 years or so, RPM has used a home-grown OpenPGP parser
for dealing with keys and signatures. That parser is rather infamous
for its limitations and flaws, and especially in recent years has
proven a significant burden to RPM development. In
On 19/10/2022 13:56, Vitaly Zaitsev via devel wrote:
On 19/10/2022 10:31, Neal Gompa wrote:
HTTPS does not help with that. It's just a transport protocol.
It will. All requests will be encrypted. ISP will only see server's
IP-address and its hostname (only if SNI is enabled).
HTTPS does
On 19-10-2022 14:51, Stephen Smoogen wrote:
On Wed, 19 Oct 2022 at 05:09, Sandro wrote:
On 19-10-2022 10:31, Neal Gompa wrote:
On Wed, Oct 19, 2022 at 4:01 AM Vitaly Zaitsev via devel
We don't have a "main mirror" for that to work.
dl.fedoraproject.org would be what this would aim at
On Wed, Oct 19, 2022 at 1:47 PM Vitaly Zaitsev via devel
wrote:
>
> On 19/10/2022 14:14, Daniel P. Berrangé wrote:
> > IOW, the impact of AES on server peformance will vary depending
> > on CPU models, NIC models / network switches and whether other
> > workloads are competing for CPU time.
On Wed, Oct 19, 2022 at 9:33 AM Neal Gompa wrote:
>
> On Wed, Oct 19, 2022 at 4:01 AM Vitaly Zaitsev via devel
> wrote:
> >
> > On 19/10/2022 09:48, Peter Robinson wrote:
> > > Sure but as mentioned it's public data, and the modification, and I
> > > covered that in my reply, would be picked up
On Wed, 19 Oct 2022 at 05:09, Sandro wrote:
> On 19-10-2022 10:31, Neal Gompa wrote:
> > On Wed, Oct 19, 2022 at 4:01 AM Vitaly Zaitsev via devel
>
> > We don't have a "main mirror" for that to work.
>
>
dl.fedoraproject.org would be what this would aim at but we would probably
have to change
Once upon a time, Vitaly Zaitsev said:
> On 19/10/2022 09:33, Peter Robinson wrote:
> >Why are they insecure? This is public open data, not banking data,
> >where the data being downloaded is verifiable by the rpm signatures
> >and signing keys.
>
> ISPs or anyone on the the same network can
On 19/10/2022 14:14, Daniel P. Berrangé wrote:
IOW, the impact of AES on server peformance will vary depending
on CPU models, NIC models / network switches and whether other
workloads are competing for CPU time. Admins need to decide
what tradeoffs are important to them.
In future, modern web
On Wed, Oct 19, 2022 at 01:56:47PM +0200, Vitaly Zaitsev via devel wrote:
> On 19/10/2022 10:31, Neal Gompa wrote:
> > HTTPS does not help with that. It's just a transport protocol.
>
> It will. All requests will be encrypted. ISP will only see server's
> IP-address and its hostname (only if SNI
On 19/10/2022 10:31, Neal Gompa wrote:
HTTPS does not help with that. It's just a transport protocol.
It will. All requests will be encrypted. ISP will only see server's
IP-address and its hostname (only if SNI is enabled).
Not in any meaningful way, and in most cases HTTPS makes mirrors
On Wed, Oct 19, 2022 at 11:25 AM Matthew Miller
wrote:
>
> I _very much_ appreciate all the work you and the other Rust SIG folks
> (Igor and Zbyszek in particular but I'm sure others as well!) have put into
> packaging rust apps and crates and all of the systems around that.
I'll respond
On Wed, Oct 19, 2022 at 10:50:19AM +0200, Sandro wrote:
> >We don't have a "main mirror" for that to work.
>
> So, this has been looked into already? It definitely sounds like it
> could help in sparsely served parts of the world at a reasonable
> cost.
Yes. I think this is basically just a
On Thu, Oct 13, 2022 at 03:46:49PM +0200, Fabio Valentini wrote:
> > The dependency on LLVM is not even the worst issue in my eyes. LLVM is also
> > used by other core projects, e.g., mesa, these days.
> >
> > The worst issue I see with Rust is the way libraries are "packaged", which
> > just
On 19-10-2022 10:31, Neal Gompa wrote:
On Wed, Oct 19, 2022 at 4:01 AM Vitaly Zaitsev via devel
wrote:
On 19/10/2022 09:48, Peter Robinson wrote:
Sure but as mentioned it's public data, and the modification, and I
covered that in my reply, would be picked up by the other mechanisms.
They
On Wed, Oct 19, 2022 at 4:01 AM Vitaly Zaitsev via devel
wrote:
>
> On 19/10/2022 09:48, Peter Robinson wrote:
> > Sure but as mentioned it's public data, and the modification, and I
> > covered that in my reply, would be picked up by the other mechanisms.
>
> They can collect a lot of sensitive
On 19/10/2022 09:48, Peter Robinson wrote:
Sure but as mentioned it's public data, and the modification, and I
covered that in my reply, would be picked up by the other mechanisms.
They can collect a lot of sensitive information: your IP, Fedora
version, packages version, etc. This can help
On Wed, Oct 19, 2022 at 8:40 AM Vitaly Zaitsev via devel
wrote:
>
> On 19/10/2022 09:33, Peter Robinson wrote:
> > Why are they insecure? This is public open data, not banking data,
> > where the data being downloaded is verifiable by the rpm signatures
> > and signing keys.
>
> ISPs or anyone on
On 19/10/2022 09:33, Peter Robinson wrote:
Why are they insecure? This is public open data, not banking data,
where the data being downloaded is verifiable by the rpm signatures
and signing keys.
ISPs or anyone on the the same network can view, intercept or even
modify HTTP/rsync traffic.
On Wed, Oct 19, 2022 at 8:17 AM Vitaly Zaitsev via devel
wrote:
>
> On 13/10/2022 15:46, Neal Gompa wrote:
> > Also, a ton of Fedora mirrors still don't use HTTPS for various reasons.
>
> I think such insecure mirrors should be removed from metalink.
Why are they insecure? This is public open
On 13/10/2022 15:46, Neal Gompa wrote:
Also, a ton of Fedora mirrors still don't use HTTPS for various reasons.
I think such insecure mirrors should be removed from metalink.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing
On Thu, Oct 13, 2022 at 03:57:41PM +0200, Kevin Kofler via devel wrote:
> > Also, a ton of Fedora mirrors still don't use HTTPS for various reasons.
> I would say that those mirrors ought to be kicked out of the mirror list
> immediately.
There are also a lot of rsync mirrors. I don't think any
On Fri, 14 Oct 2022 18:28:01 +0200,
Simo Sorce wrote:
> At this time, as far as I know, there is no OpenPGP work of any kind on
> supporting PQC algorithms.
The German BSI contracted MTG AG to design and implement PQC for
OpenPGP. They presented their work at IETF 113, and at the OpenPGP
email
On Fri, 2022-10-14 at 10:14 +0300, Panu Matilainen wrote:
> On 10/13/22 15:14, Neal Gompa wrote:
> > On Thu, Oct 13, 2022 at 4:24 AM Panu Matilainen wrote:
> > >
> > > On 10/13/22 10:53, Neal Gompa wrote:
> > > > On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen
> > > > wrote:
> > > > >
> > > >
On 10/13/22 15:14, Neal Gompa wrote:
On Thu, Oct 13, 2022 at 4:24 AM Panu Matilainen wrote:
On 10/13/22 10:53, Neal Gompa wrote:
On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen wrote:
On 10/13/22 07:18, Kevin Kofler via devel wrote:
For the last 20 years or so, RPM has used a home-grown
On 10/13/22 17:31, Neal Gompa wrote:
On Thu, Oct 13, 2022 at 9:58 AM Kevin Kofler via devel
wrote:
Neal Gompa wrote:
No, because when you do things like mirror repositories (especially
for private mirrors), that signature is the only way to verify the
integrity. HTTPS is only transport
On 10/13/22 19:35, Demi Marie Obenour wrote:
On 10/13/22 04:23, Panu Matilainen wrote:
On 10/13/22 10:53, Neal Gompa wrote:
On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen wrote:
On 10/13/22 07:18, Kevin Kofler via devel wrote:
For the last 20 years or so, RPM has used a home-grown OpenPGP
Let's Encrypt also supports the dns-01 challenge[1] that doesn't require
any publicly available IPs. Using dns verification is required to obtain a
Let's Encrypt wildcard certificate.
While I tend to prefer using the dns-01 challenge approach
when possible, not all DNS providers have made it
On Thu, Oct 13, 2022 at 4:57 PM Maxwell G via devel
wrote:
> Let's Encrypt also supports the dns-01 challenge[1] that doesn't require
> any publicly available IPs. Using dns verification is required to obtain a
> Let's Encrypt wildcard certificate.
While I tend to prefer using the dns-01
On 10/13/22 11:28, Demi Marie Obenour wrote:
systemd (yes, systemd)
is considering using Rust, though it has not yet started including it,
and there is already Rust code in Mesa IIRC.
Don't forget the Python 'cryptography' package... also a Rust user. It's
here to stay, at least for the
On Thu Oct 13, 2022 at 17:12 +0200, Kevin Kofler via devel wrote:
> > And using Let's Encrypt for private mirrors is sufficiently painful that I
> > wouldn't recommend it.
>
> Set up a subdomain like vpn.example.com, point it to the public IP, then
> configure the VPN's internal DNS to resolve
On 10/13/22 04:23, Panu Matilainen wrote:
> On 10/13/22 10:53, Neal Gompa wrote:
>> On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen wrote:
>>>
>>> On 10/13/22 07:18, Kevin Kofler via devel wrote:
> For the last 20 years or so, RPM has used a home-grown OpenPGP parser
> for dealing with
On 10/13/22 11:18, Kevin Kofler via devel wrote:
> Fabio Valentini wrote:
>> Do you have suggestions for improving this situation? I think we're
>> pretty close to doing the best we can with packaging Rust projects,
>> given the current limitations of the language (i.e. the support for
>> building
On Thu, Oct 13, 2022 at 11:38 AM Demi Marie Obenour
wrote:
>
> On 10/13/22 08:14, Neal Gompa wrote:
> > On Thu, Oct 13, 2022 at 4:24 AM Panu Matilainen wrote:
> >>
> >> On 10/13/22 10:53, Neal Gompa wrote:
> >>> On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen
> >>> wrote:
>
> On
On 10/13/22 08:14, Neal Gompa wrote:
> On Thu, Oct 13, 2022 at 4:24 AM Panu Matilainen wrote:
>>
>> On 10/13/22 10:53, Neal Gompa wrote:
>>> On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen wrote:
On 10/13/22 07:18, Kevin Kofler via devel wrote:
>> For the last 20 years or so, RPM
On Thu, Oct 13, 2022 at 3:13 PM Kevin Kofler via devel
wrote:
>
> Neal Gompa wrote:
> > I'm not going to get into this too much, but suffice to say, it's not
> > universally accessible as a CA.
>
> I would very much be interested in those details though.
As I recall, the current LE root
Fabio Valentini wrote:
> Do you have suggestions for improving this situation? I think we're
> pretty close to doing the best we can with packaging Rust projects,
> given the current limitations of the language (i.e. the support for
> building "true shared Rust libraries" is still very limited and
Neal Gompa wrote:
> I'm not going to get into this too much, but suffice to say, it's not
> universally accessible as a CA.
I would very much be interested in those details though. I do not see
anybody being excluded from Let's Encrypt, not even countries under US
embargo (e.g., over 30
On Thu, Oct 13, 2022 at 9:58 AM Kevin Kofler via devel
wrote:
>
> Neal Gompa wrote:
> > No, because when you do things like mirror repositories (especially
> > for private mirrors), that signature is the only way to verify the
> > integrity. HTTPS is only transport encryption from a particular
>
Neal Gompa wrote:
> No, because when you do things like mirror repositories (especially
> for private mirrors), that signature is the only way to verify the
> integrity. HTTPS is only transport encryption from a particular
> connection.
HTTPS protects against a MITM on the connection introducing
On Thu, Oct 13, 2022 at 3:31 PM Kevin Kofler via devel
wrote:
>
> The dependency on LLVM is not even the worst issue in my eyes. LLVM is also
> used by other core projects, e.g., mesa, these days.
>
> The worst issue I see with Rust is the way libraries are "packaged", which
> just implies
On Thu, Oct 13, 2022 at 9:31 AM Kevin Kofler via devel
wrote:
>
> Neal Gompa wrote:
> > This is also the underlying reason why Red Hat has resisted
> > implementing signed repository metadata and enforcing it by default.
> > Of course this is a bit of a catch-22 as well, as there's no
> >
Neal Gompa wrote:
> This is also the underlying reason why Red Hat has resisted
> implementing signed repository metadata and enforcing it by default.
> Of course this is a bit of a catch-22 as well, as there's no
> motivation to find a solution because neither Fedora nor RHEL offer
> signed
On Thu, Oct 13, 2022 at 4:24 AM Panu Matilainen wrote:
>
> On 10/13/22 10:53, Neal Gompa wrote:
> > On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen wrote:
> >>
> >> On 10/13/22 07:18, Kevin Kofler via devel wrote:
> For the last 20 years or so, RPM has used a home-grown OpenPGP parser
>
On 10/13/22 10:53, Neal Gompa wrote:
On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen wrote:
On 10/13/22 07:18, Kevin Kofler via devel wrote:
For the last 20 years or so, RPM has used a home-grown OpenPGP parser
for dealing with keys and signatures. That parser is rather infamous
for its
On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen wrote:
>
> On 10/13/22 07:18, Kevin Kofler via devel wrote:
> >> For the last 20 years or so, RPM has used a home-grown OpenPGP parser
> >> for dealing with keys and signatures. That parser is rather infamous
> >> for its limitations and flaws, and
On 10/13/22 07:18, Kevin Kofler via devel wrote:
For the last 20 years or so, RPM has used a home-grown OpenPGP parser
for dealing with keys and signatures. That parser is rather infamous
for its limitations and flaws, and especially in recent years has
proven a significant burden to RPM
> For the last 20 years or so, RPM has used a home-grown OpenPGP parser
> for dealing with keys and signatures. That parser is rather infamous
> for its limitations and flaws, and especially in recent years has
> proven a significant burden to RPM development. In order to improve
> security and
Hi Ben,
Ben Cotton wrote:
Within Fedora package set, this has no impact as everything is already
using sufficiently strong crypto. Third party repositories / packages
could be signed with insecure crypto, and those may require working
around with --nosignature. However this incidentally
https://fedoraproject.org/wiki/Changes/RpmSequoia
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
https://fedoraproject.org/wiki/Changes/RpmSequoia
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
86 matches
Mail list logo
