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 c
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 has
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 run
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 w
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 "bundlin
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 the
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 case
> 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 libraries
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. Of
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 OS-
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 rust-[crate
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 th
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&packages=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 PQ
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 f
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 te
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 m
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 agre
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: cle
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 librar
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:
ht
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 i
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 en
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 at
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 1
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 no
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
___
de
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 sign
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 AM
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 re
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 or
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 not
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 b
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. Admins
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 b
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 the
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 view
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 b
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 i
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 sl
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 inline.
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 matte
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 impli
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 ca
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 i
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 wi
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.
T
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 dat
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 li
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 o
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 su
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 O
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 encryp
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 eas
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 challen
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 forese
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 vpn
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 key
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 10/13
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 ha
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 certifica
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 site
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 i
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 install
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
> > motivati
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 reposi
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 limit
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 e
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 developm
> 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 fre
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 overla
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.
=
85 matches
Mail list logo
