i586 <-> i686 is exactly the same class as i586 <-> i686 when the color is zero
for one of the rpms.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2837#issuecomment-1896129493
You are receiving this because you are subscribed to this
An example would be: https://bugzilla.redhat.com/show_bug.cgi?id=966715
Don't you think an architecture change from i585 to i686 should delete the i586
package even if the NEVR is the same?
--
Reply to this email directly or view it on GitHub:
Regarding the original report: I'm not sure it is related to this issue. dnf5
should be able to replace multiple versions of an installed package. I'm not
sure the original problem is a multilib issue.
--
Reply to this email directly or view it on GitHub:
What's so special about an identical NEVR? The content may still be different,
we had a couple of bug reports about same NEVR with different files and rpm not
doing the correct thing.
--
Reply to this email directly or view it on GitHub:
Do we really want to do something special for "same NEVR"? I find that a bit
weird.
(But all that color handling is also super weird to me, and dnf/zypper also
does not know the package colors when calculating the transaction and has to
hope that the architecture matches the color.)
(BTW, is
AFAIR if the packages contain no files, they wont get any color.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2837#issuecomment-1889371001
You are receiving this because you are subscribed to this thread.
Message ID:
Should the `m` lines generate user()/group() requires?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2816#issuecomment-1855994282
You are receiving this because you are subscribed to this thread.
Message ID:
Does it make sense to add support for 'm' lines in sysusers config files? This
would mean the following changes:
- add a provides for every `m` line, e.g. "group-member(groupname) =
base64_line"
- feed all such provides to systemd_sysusers tool (after all the user/group
lines)
The sysusers.sh
No, the code works fine. I'll just to another pull request to tidy it up a bit
and add some test cases.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2788#issuecomment-1851633255
You are receiving this because you are subscribed to
But... it wasn't meant to be merged yet, thus the "RFC" in the name. There's
testcases missing, and I don't like that `RPMEXPAND_HAVE_QUOTED` is actually a
result, not an input. Next time I'll add the "Dont't merge yet" label.
--
Reply to this email directly or view it on GitHub:
This is actually a quite powerful. Try this:
```
%define hey() {
this is hey
%{shescape %**}
%**
ho
}
%global array foo bar %{quote:hello world} %%{quote:huhu foo}
%global xx x1 %{quote:x2 x3}
%global array %array %{quote:aa %%xx} %%xx
%global array %array %{quote:rpm is great} rpm is
@mlschroe pushed 1 commit.
affb2e8d2e460c6e25dd579eac0f36822da0fa3e Strip quote characters in macro
expansion if we do not split the result
--
View it on GitHub:
A problem with the old handling of %quote was that it leaked to the outside.
This commit strips the quote characters if they are not used in argument
splitting.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2788
--
Also: make it possible to specify a glob instead of a prefix.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2655#issuecomment-1715657632
You are receiving this because you are subscribed to this thread.
Message ID:
Sorry, I misremembered. I thought it was you who reported this in our bugzilla,
but it was Jiri:
https://bugzilla.suse.com/show_bug.cgi?id=1213277
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2605#issuecomment-1670885836
You are
Is this a request to backport the glob changes to the 4.18 maintenance branch?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2605#issuecomment-1669769590
You are receiving this because you are subscribed to this thread.
Message ID:
You can do many nasty things with %ifarch, e.g. not include some patch on an
architecture. (But is is probably against the packaging guidelines of any
distribution.)
--
Reply to this email directly or view it on GitHub:
This came up because the systemd folks have transfiletrigger lua scripts that
do stuff like:
```
assert(rpm.execute("udevadm", "control", "--reload"))
```
If the udevadm call fails, you'll get a weird error message like `Unknown
error 16640`
--
Reply to this email directly or view it on
rpm_execute does a `pushresult(L, status, NULL)`. `pushresult` expects the
second argument to be either zero (call ok) or an errno number (call failed).
(All the pushresult/pusherror calls seem to be somewhat bogus...)
--
Reply to this email directly or view it on GitHub:
I dunno about that "fine" and "incomplete". You're asking to *remove* an extra
check in the internal pgp parser.
So maybe the sequoia code is incomplete.
Basically the API is missing a type argument to tell the parser if it should
test for a certain armor.
--
Reply to this email directly or
I'd argue that either rpm-sequoia or the internal implementation should be
fixed. I'm not sure which is correct.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1554228061
You are receiving this because you are
I would be more happy if it does the local parsing only in the chroot case,
like with my old patch.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2503#issuecomment-1540219256
You are receiving this because you are subscribed to this
(Oh, and changing the default of `--whatrequires` would maybe improve things
for Fedora, because rpm behaves more like repoquery. But I'll get bug reports
from SUSE users, as rpm no longer matches what zypper does. Just saying... ;-) )
--
Reply to this email directly or view it on GitHub:
(Sorry about that history comment. I should read your bug references first...)
There's also the question if the query should use the current state of
installed packages or do "potential" matches. Say installed package A contains
a requires `(B or C)`. Should `--whatrequires B` return A if C is
Oh, and just one last note: there are basically three ways to to a
--whatrequires query:
--whatrequires STRING
Which packages have the exact string as a dependency? STRING could maybe be a
glob, we could support case insensitive searches, rich deps like `(foo if bar)`
are allowed.
Having said that, I want to point you to
https://bugzilla.redhat.com/show_bug.cgi?id=1534123 that is about simply adding
the provides no longer being correct with rich dependencies. I had to add a new
function to libsolv (`pool_whatmatchessolvable`) so that dnf could do the
query.
--
Reply
The history here seems to be yum's repoquery tool. It had a `--alldeps` option
from the start, which made it extend the query with the provides of the
specified package.
Commit
https://github.com/rpm-software-management/yum-utils/commit/bc3d026acd1c8f332d024bf9a9918da6451c8c07
made `--alldeps`
Wouldn't you also want to do a `rpmdsCompare` like in `checkInstDeps`?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2451#issuecomment-1482859306
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:
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
Sorry for not commenting earlier, this was a busy week.
It's true that this can be done in the specfile, but that can lead to each
individual package maintainer using a different way. I think it's worthwhile
that the mechanism is the same for all distributions. The goal is exactly that
it
The bcond mechanism of rpm allows to specify a default for a feature in a spec
file, which can be overridden with the command line. SUSE wants to build
packages with the same source in different projects. Thus we need a way to
specify a default via an rpm macro.
Our first try was to misuse the
I hope I get this right, because I'm no expert for that topic either.
SBOM is "Software bill of materials". Basically it is a document that describes
what exactly is on a product/appliance/container/... There are two standard
formats, SPDX and CycloneDX, coming from different directions.
SPDX
But but but... where have you been? Software supply chain security is the thing
nowadays ;-)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2389#issuecomment-1424220433
You are receiving this because you are subscribed to this thread.
Yes, this is a documentation issue.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2064#issuecomment-1424217697
You are receiving this because you are subscribed to this thread.
Message ID:
(See the SPDX documentation for something similar)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2064#issuecomment-1424092752
You are receiving this because you are subscribed to this thread.
Message ID:
Sorry for chiming in so late, but is this really `:`? e.g.
`git:git://foo.com/...`? Many other formats use `git+https://github.com` or
similar.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2064#issuecomment-1424089548
You are
I'm currently looking into generating SBOMs for container, and I wonder if
someone has already pondered if we want to store SBOM data in an rpm header.
Here's where I come from: SBOM generator tools like "syft" support both
querying the systems package database to know what packages are
My guess is that this is the same as #1326
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2382#issuecomment-1420729380
You are receiving this because you are subscribed to this thread.
Message ID:
It's not hard to fix this for the macro file case. But the spec file case is a
bit nastier.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2353#discussioncomment-4708013
You are receiving this because you are subscribed to this
I always considered this not working to be a bug.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2353#discussioncomment-4707883
You are receiving this because you are subscribed to this thread.
Message ID:
What's happening is that the macro expansion happening in the expression code
pops the macro arguments, because the macro level is not correct. We had this
problem with lua as well. See commit 1767bc4fd82bfacee622e698f9f0ae42c02126fa.
A fix would be to change the doExpressionExpansion code to
I just had a use case where I needed glob matching in an rpm expression. Is
that something we should add?
We could define a new operator like `"string" ~~ "glob"` or hijack an existing
one that currently throws an error like `"string" * "glob"`. Of course we can
also use a function like
What's the state of this pull request? Can this be merged now?
I would need to add support for the new architectures to libsolv as well.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1362649807
You are receiving this
(Bottom line being: only use BuildArch for `BuildArch: noarch`. All other uses
are not tested and also not documented.)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1352902953
You are receiving this because you are
Just a data point: when I created ndb I played with putting lzo compressed
headers in the database. I thought that decompression would be faster than IO,
so the net result would be faster database access. But it turned out that
things got slower with compression, so I removed the feature again.
It should be available in 15.3 and 15.4.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2323#issuecomment-1350770444
You are receiving this because you are subscribed to this thread.
Message ID:
15.5? That's not released yet, right? I don't know if it contains any
maintenance updates.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2323#issuecomment-1350769608
You are receiving this because you are subscribed to this thread.
(I think this should already be fixed with the latest maintenance update. I'm
not sure if it is already released, though.)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2323#issuecomment-1348556094
You are receiving this because you
The documentation is somewhat lacking, but it seems to me that once upon a time
specifying multiple elements in BuildArch resulted in multiple builds being
done (if the buildarch is deemed compatible).
I think this was broken in 2001 with commit
c3835f5ca0e3ea856213a22367233e148ea26550, which
I don't understand this. Do you want me to use something different than
rpmsign? Because rpmsign used to copy the lead, but commit
3255273ae0fabd03c9738249a29c9c1e15f28f64 changed it to regenerate the lead
instead of copying over.
--
Reply to this email directly or view it on GitHub:
See the comment in rpmLeadFromHeader (as I wrote):
```
/* FIXME: should grab these from header instead (RhBug:717898) */
rpmGetArchInfo(NULL, );
rpmGetOsInfo(NULL, );
```
So you'll get the arch from the host where you created or deleted a signature,
and not the arch from
pens to hash to the same value, i.e. a
preimage attack on the hash.
Cheers,
Michael.
--
Michael Schroeder SUSE Software Solutions Germany GmbH
m...@suse.de GF: Felix Imendoerffer HRB 36809, AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)
ys/crypto/fips_enabled and enforce restrictions in FIPS mode.
Cheers,
Michael.
--
Michael Schroeder SUSE Software Solutions Germany GmbH
m...@suse.de GF: Felix Imendoerffer HRB 36809, AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13
s to make it configurable.
I.e. we would add a "%_allowed_signature_hashes" or
"%_forbidden_signature_hashes" so that we the admins can tweak
it to their needs.
Cheers,
Michael.
--
Michael Schroeder SUSE Software Solutions Germany GmbH
m...@suse.de GF: Fel
@mlschroe commented on this pull request.
> @@ -422,8 +422,6 @@ static int pgpVerifySigEDDSA(pgpDigAlg pgpkey, pgpDigAlg
> pgpsig, uint8_t *hash,
return rc;
if (pgpkey->curve != PGPCURVE_ED25519)
return rc;
-if (hash_algo != PGPHASHALGO_SHA256)
- return rc;
I
No objections from my side. Take it out into the back garden and end its
suffering...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I just looked at the commit that changed the requires from 5.2 to 5.3, and that
one did not include the INSTALL part. Sorry.
Updated and force-pushed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe pushed 1 commit.
53da480b245f0e1dfb1d518a2cdc8373a47b52d4 Use lua_replace instead of lua_rotate
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Ohh, non-emptyness instead of plain definedness? Like in most shells:
`${foo-bar}` versus `${foo:-bar}`...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
lua_rotate works but is somewhat the wrong tool if we just
want to set a specific stack element. Use lua_replace instead.
This has the added advantage that the code works again with
lua version 5.2 (not that it matters much).
You can view, comment on, or merge this pull request online at:
I added the documentation and rebased the commit to the new macro code.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
But that's wrong. Configure's --target option is meant to be used to define the
generated arch when building a cross compiler. E.g. if you want to build a
cross compiler for aarch64 that runs on your x86_64 host. But the generated rpm
that contains the cross compiler will still be x86_64.
Note
That's because rpm is confused about the cross option naming. Rpm uses --target
to specify the host arch the generated rpms should run on (i.e. the "host" in
GNU option speech). See issue #1650 ...
We probably have to add a new option `--codegen-target` that can be used to
feed configure's
Yes, I think this can be merged if you're fine with the changes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
On Mon, Oct 25, 2021 at 05:32:38PM +0200, Justus Winter wrote:
> Michael Schroeder writes:
>
> > On 10/21/21 18:12, Justus Winter wrote:
> >> First, I think replacing RPM's point solution with a general purpose
> >> implementation will improve correctness.
Just thinking out loud:
```
%{!foo:bar}
%{?foo-bar}
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
(force pushed because I added a testcase for the last commit)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe pushed 1 commit.
fa3c6df29bfce68ffa24daf56623dd4c3c9ea497 Support non-parametric builtins again
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@mlschroe pushed 1 commit.
5ede2ac87470251ab263a38cb1da54dc8a54dfe8 Support non-parametric builtins again
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
%expand is not ME_PARSE, so it grabs the args till the end of line. It also
does arg splitting and just uses the first arg, which is maybe not what we want:
```
./rpm --eval '%expand hello world'
hello
```
We could disable the arg splitting with some new flag, but I don't think
builtins should
Ok, all done for now. Things to discuss:
Should `rpm --eval '%lua print("foo")'` work? This is pretty trivial to do,
it's also consistent with the other macros but it's also somewhat weird.
Should we make the zero-arg builtins non-parametric? I.e. should 'make -j
%getncpus all` work? (It used
@mlschroe pushed 3 commits.
16a2ba8929f85b04a238033ad0348521b149b527 Rename doExpandThisMacro to doMacro
8fd5048f11eacca4a9c9c421424d57a5baf7f03e Special case the non-parametric and
the free-field macro expansion
81258f1e660d7980720dd67449d6d26d75935ff1 Make %{define foo body} not use the
ackend to the Rust compiler [4], and to write a Rust frontend
> for GCC [5].
But doesn't that mean that we need to wait till this work is done?
Cheers,
Michael.
--
Michael Schroeder SUSE Software Solutions Germany GmbH
m...@suse.de GF: Felix Imendoerffer HRB 36809, AG Nuernberg
m
@mlschroe pushed 1 commit.
0babaaf9d0e74e1066a667be9d3451a80f10a0aa Add a "parsed" argument to the
doXXX() functions
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
WIP, other commits are coming.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1809#issuecomment-950638814___
Rpm-maint mailing
Fix inconsistencies in macro parameter expansion for builtin macros.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1809
-- Commit Summary --
*
Is it ok for you if I make `%{define foo bar}` work? Currently, `%{define foo
bar}` is the same as `%define`, which is kinda sad. I'd rather have it behave
like `%{define:foo bar}`.
Can I also change `%{define:foo bar}` to not use that super weird free-field
parser? I'd prefer to make it work
We also broke `%{undefine} foo`, but I think nobody will complain ;-)
And `%undefine foo bar` expanded to ` bar` in rpm-4.16, now it just silently
eats up everything coming after the name.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
Another glitch we have introduced with rpm-4.17:
```
$ rpm-4.16 --eval '%getconfdir foo'
/usr/lib/rpm foo
$ rpm-4.17 --eval '%getconfdir foo'
error: %getconfdir: unexpected argument
```
I.e. builtins with nargs == 0 are incorrectly marked as parametric.
--
You are receiving this because you are
Rpm's %define implementation is so weird:
```
$ rpm --eval '%define foo bar\baz' --eval '%foo'
barbaz
$ rpm --eval '%define foo {bar\baz}' --eval '%foo'
bar\baz
```
I saw that you added support for a "programmatic" case where the macro name is
one arg and the body is the second arg. Should rpm
Switching to ME_PARSE is not as easy as I thought. And there are some other
problems as well:
```
$ rpm --eval '%{define:foo bar
baz}
%foo'
bar
```
I don't think it should throw away the baz part.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
While musing about if %verbose should expand its arg I stumbled over two things:
1) The new %shescape macro does not expand its argument:
```
$ rpm --eval '%{shescape:%%}'
'%%'
```
2) We have an unintended discrepancy between %{foo:arg} and %{foo arg}: the
former does not expand the arg, the
@mlschroe commented on this pull request.
> + 0x99,
+ (pkt->blen >> 8),
+ (pkt->blen ),
That may be, but it's what the spec says. It's not a security problem because
the complete package is hashed anyway. V5 keys hash the complete length, not
just the lowest
@mlschroe commented on this pull request.
> }
}
- if (pgpPrtPkt(, digp))
+ if (digp->tag == PGPTAG_PUBLIC_KEY && pkt->tag == PGPTAG_SIGNATURE)
+ selfsig = pgpDigParamsNew(pkt->tag);
Maybe it's me ;)
My point is that selfsig will also be set for
@mlschroe commented on this pull request.
> + (pkt->blen >> 24),
+ (pkt->blen >> 16),
+ (pkt->blen >> 8),
+ (pkt->blen ),
+};
+rpmDigestUpdate(hash, head, 5);
+rpmDigestUpdate(hash, pkt->body, pkt->blen);
+}
+
+static int pgpVerifySelf(pgpDigParams key,
@mlschroe commented on this pull request.
> }
}
- if (pgpPrtPkt(, digp))
+ if (digp->tag == PGPTAG_PUBLIC_KEY && pkt->tag == PGPTAG_SIGNATURE)
+ selfsig = pgpDigParamsNew(pkt->tag);
Sure, but that's a problem as the signature checking code below is
@mlschroe commented on this pull request.
> }
}
- if (pgpPrtPkt(, digp))
+ if (digp->tag == PGPTAG_PUBLIC_KEY && pkt->tag == PGPTAG_SIGNATURE)
+ selfsig = pgpDigParamsNew(pkt->tag);
Maybe you should also check that the issuer id matches and ignore
@mlschroe commented on this pull request.
> break;
+ if (pkt->tag == PGPTAG_PUBLIC_SUBKEY)
+ expect = PGPTAG_SIGNATURE;
Should we also enforce a self-sig on a User ID Packet?
--
You are receiving this because you are subscribed to this thread.
Reply to this email
@mlschroe commented on this pull request.
> if (pkttype == PGPTAG_SIGNATURE)
break;
+
+ if (alloced < i) {
Shouldn't that be `alloced <= i`?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe commented on this pull request.
> }
}
- if (pgpPrtPkt(, digp))
+ if (digp->tag == PGPTAG_PUBLIC_KEY && pkt->tag == PGPTAG_SIGNATURE)
+ selfsig = pgpDigParamsNew(pkt->tag);
The code assumes that the self-sig always comes first if there are
@mlschroe commented on this pull request.
> + (pkt->blen >> 24),
+ (pkt->blen >> 16),
+ (pkt->blen >> 8),
+ (pkt->blen ),
+};
+rpmDigestUpdate(hash, head, 5);
+rpmDigestUpdate(hash, pkt->body, pkt->blen);
+}
+
+static int pgpVerifySelf(pgpDigParams key,
@mlschroe pushed 1 commit.
a917182859f21602e5fa212542c0ddb08b753b90 Allow an optional argument for the
%verbose macro
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
(We could simplify this a bit if we change the ME_PARSE macros nargs
definitions from -1 to 1.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This improves compatibility with old rpm versions. If the argument is present,
the macro expands to it in verbose mode and to an empty string if not in
verbose mode.
I created this patch because people were asking me for a way to check for
verbose mode that works both in old and new rpm
We now only invaludate the cache if the cached entry is written
or deleted. This is needed for the code in rpmdbNextIterator()
which first reads the next header and then writes the modified
old header to the database. Therefore we must not free the cache
if a modified header with a different id is
I don't think this is a bug, it behaves exactly like `%{version}`. You'll
always get the values of the last definition for the macros, i.e. from the last
subpackage.
If you want the definitions of the main package, you're supposed to uppercase
the macro names, e.g. `%{EPOCH}` and `%{VERSION}`.
But you do know that we'll need to support V5 keys in the near future. So you
can design your code so that adding them is not harder than it needs to be.
With this pull request, I'd recommend to store the full fingerprint including
the last 8 bytes and adding a fingerprint length as well. I.e.:
Oops, that's an expired version. The current one is:
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-03.txt
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Note that V5 fingerprints are 32 bytes, not 20 bytes. You might want to take
that into account so that we have less work to do when supporting V5 keys.
See: https://www.ietf.org/archive/id/draft-ietf-openpgp-rfc4880bis-10.txt
--
You are receiving this because you are subscribed to this
101 - 200 of 789 matches
Mail list logo
