@mlschroe there are still DSA keys in use somewhere?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2723#issuecomment-2059388504
You are receiving this because you are subscribed to this thread.
Message ID: __
I would think people can just install those w/o checking the signatures ... but
I am not advocating against fixes
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2723#issuecomment-2063889533
You are receiving this because you are subscrib
**Describe the bug**
I have spent some time trying to create a completely custom debuginfo file for
a package I maintain.
Currently it is not possible to do so. Even disabling the custom package
template and the whole debug_package machinery via `%global debug_package
%{nil}` if rpm build see a
@ffesti the one I worked on is a bit contrived, let me see if I can create a
synthetic one form one of my Fedora packages
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3061#issuecomment-2075096251
You are receiving this because you are
Ok here is an example, apply this diff to
https://src.fedoraproject.org/rpms/pkcs11-provider
```
$ git diff
diff --git a/pkcs11-provider.spec b/pkcs11-provider.spec
index b254afa..993d353 100644
--- a/pkcs11-provider.spec
+++ b/pkcs11-provider.spec
@@ -1,4 +1,5 @@
#Enable gpg signature verificat
At the same time if you remove the two lines I added to `%install` (but lave
everything else in place including the `%files debuginfo` section) instead of
getting an error that the file was not found you get simply no debuginfo
package created at all .. and no error.
--
Reply to this email dir
or we need a "binary changelog" next to the "spec changelog" in
> the rpm itself?
I think this is going too far and should be explicitly be considered
out of scope.
For many build systems the reason why you are doing a rebuild is fully
confined within the builds productio
Well it depends at what level you are asking.
I can give you openssl commands that use oqs-provider and will let you generate
keys and apply raw signatures.
But I assume you want to see a PGP command line app that will generate a PQ
signature instead?
In that case we should probably ask someone l
Or even two RSA signatures with different keys ..
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3363#issuecomment-2413847515
You are receiving this because you are subscribed to this thread.
Message ID: ___
Is there any chance we can start testing something by applying both an RSA and
an ECDSA based signature? And later we replace one of them with a PQ algorithm ?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3363#issuecomment-2413846577
It would be a nice feature though, it would allow to have backup keys or slowly
rotate keys.
Of course it would need to allow verification to be marked ok with a single
signature verifying providing the other has a missing verification key ... fun
times.
--
Reply to this email directly or view
So currently RPM only allows one signature per type?
I think we can still work with that, but it also means signatures can't be
completely opaque to RPM and will need to allocate an ID for each signature
type ?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softwar
Cryptographic support will not be an issue, we already have support in OpenSSL
via liboqs+oqs-provider and OpenSSL will natively integrate ML-KEM / ML-DSA /
SLH-DSA in due time.
Nettle has a ML-KEM implementation and is receiving a ML-DSA one.
We will need two distinct signature packets to make
**The problem**
With the standardization of the new Quantum Safe algorithms from NIST and the
pressure from US and international agencies to adopt Quantum Safe asymmetric
cryptography it is time to consider how this will be done in RPMs.
**Context**
In the past, new algorithms would take years,
Do we even need a label ?
Pretty sure openpgp packets have a signature ID somewhere embedded in the
packet.
As for legacy support perhaps we just copy in the traditional header only one
v4 signature of the supported type. That is, we put all signatures in the new
header in whatever format openpg
> (Why are v3 sigs gone? I don't think this is true.
Are you aware of maintained OSs that can't deal withv4 signatures?
> And why would the signature version matter to rpm now that the pgp parsing is
> no longer in the code?)
Backwards compatibility with currently supported OSs (o the market) t
Sounds reasonable that --resign will drop all signatures and add new ones.
I think the only potentially missing case here is the desire to drop only a
specific signature.
The reason to do that is if you have a package with multiple signatures and you
want to replace only one that had a signing k
@JanZerebecki sorry but I do not understand your objection, any vendor can
--addsign and add a new signature w/o problems ...
The signatures themselves are not covered, they only sign the payload, so
reproducibility is not an issue.
--
Reply to this email directly or view it on GitHub:
https:/
Also having signatures in a separate file is a really bad user experience, as
now you have to coordinate distributing and keeping around two separate files.
Having signatures embedded in the rpm is a big big plus.
Detached signatures are generally a crutch and better avoided whenever possible.
Your example assumes the user will not be able to ensure a specific signature
is in the rpm, but @pmatilai in his list added explicitly the ability for rpm
-qi to list signatures, so the user can verify that a signature that purports
to be from a vendor exists, and you can verify the signature v
@JanZerebecki
This work is meant to create the conditions to move to new signatures over time
while retaining backwards compatibility.
A draconian policy that does not contemplate the possibility of getting an RPM
with unknown signatures would make any transition impossible. I am sure it
shou
The encoding does not affect the feature for me so I have no opinion.
Some PQ signatures can be big.
The scheme that has the biggest signatures for now is SLH-DSA (formerly known
as SPHINCS+) and the stronger variant has a signature size of 50KiB.
ML-DSA's (aka Dilithium) biggest signature is ~
@Conan-Kudo the simplest policy is that signatures must all verify (why would
you put multiple of them otherwise?).
The tricky part is how to handle signatures you do not understand, and I think
the simplest policy, again, is to ignore those.
Note, I am not saying you should ignore signatures
I know what malleability means, what makes no sense to me is your claim, out of
the blue, that the official way to release PGP signatures in printable form is
somehow vulnerable to confounding attacks, and how they would be relevant here.
If the signature validates it is a valid signature and th
Just to be clear I do not consider it reasonable to apply signatures to the
content and then again additional signatures just to the headers, that would
create a matrix explosion of possibilities rather quickly, and render both
policy and testing needlessly complicated.
--
Reply to this email
I do not think we want to get into the rabbit hole of considering multiple
signatures this way.
If people really want to bind multiple signatures together they will be able to
issue a hybrid signature in future that does the proper binding at the
signature level.
If you still wanted to sign hea
If the header with the signatures is excluded all that needs to be defined is
only what else and in which order needs to be signed, and I think a single
signature covering all is just fine.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/iss
Adding signatures is in fact a great feature in my view, as it allows to
additionally validate by 3rd parties that a package is ok to be consumed
withtout having to completely remove the original signatures.
For example: Linux vendor releases package XYZ-1.2.3 signed with RSA and
SLH-DSA, later
> I strongly oppose ASCII armor, as it injects a lot of additional malliability.
What does that even mean?
It is just a format with no ambiguity in representation.
Given the current code wants ASCII I would definitely just use the ASCII
Armored signature directly and avoid the silly step. I see
Unsure if this is possible with RPM,
but if there was a way to add hashes calculated from the headers as data in he
signed payload without the need to further modify said headers, then you could
make this backwards compatible in the sense that older version of RPM would
still check the classic s
Sounds like something that should not be added hastily.
Is he initial description of "protecting" file signatures the only reason to do
this?
What is the attack vector here?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2224#issuecomm
simo5 left a comment (rpm-software-management/rpm#3363)
This is going to be an issue for implementations that want to use a cloud HSM
to perform signatures, as you do not want to ship potentially gigabytes of data
over the network, so it will require specialized software to select a salt
outsid
simo5 left a comment (rpm-software-management/rpm#3057)
@judovana it is not complicated, because the debug info extraction was "broken"
on the "main" package I created subpackages instead, so in the spec (this is a
library that ships only .so files) I have something like:
```
%global debug_pac
33 matches
Mail list logo
