my bad, should be fixed now
ah yeah, it was just a mistake
I also backported the fix of a regression visible in compiler tests while building. (https://github.com/ziglang/zig/issues/16680)
I hope the APKBUILD is fine.
Aydin Mercan (629c3021) at 06 Aug 21:51
testing/zig: upgrade to 0.11.0
Aydin Mercan (5baadf39) at 06 Aug 21:42
Merge branch aports:master into master
... and 31 more commits
Aydin Mercan (ff8f6828) at 06 Aug 21:30
testing/zig: upgrade to 0.11.0
(...) users explicitly requiring EC with NIST curves
How significant is this user population? If it isn't that many, maybe we could get away by gently pushing it to the legacy function API and/or make it a build-time choice that is turned off by default. Fortunately it shouldn't(?) pose a barrier to transitioning out libcrypto either way.
I am mainly suggesting 3 things:
The last point might seem unnecessary but from the view does the developer really want to specify what to use (algorithm, PKEY
functions etc.) apart from "give me a checksum" or "verify this"? By doing so we can make things mostly misuse-free. I admit it would working both separate new and legacy functions might be a bit tedious but in the long term using it should be trivial to sail with. (and drop what is unnecessary)
Sorry for the sudden silence, I had started my co-ed in a new workspace which kept me busy for a while. I see that @fabled has started some the work but does anyone need to MD5 or SHA-1 (or rather, naming the algorithm to the developer) outside legacy purposes?
On the side note, I would like to propose switching to a signify/minisign like signature format to make things easier and more robust. Apart from not needing untrusted comments, our ID/random byte field is double of minisign/signify so coming up with the tooling should be hard?
From AlpineConf I remember some discussion about the need of a PKI so depending on the topology the format could be expanded although making things overcomplicated wouldn't be very fun in the end
A transition period is completely reasonable. I misunderstood the situation as not switching at all to allow for potential FIPS compatibility. If the FIPS 186-5/NIST SP 800-186 draft isn't approved by the time we deprecate RSA it should be the user's problem to ensure apk remains FIPS compliant.
Is there a reason to not just rotate keys from the release with apk 3.0? Most attacks on RSA-PKCS1v15 don't apply to our case since apk operations are "offline", however it still suffers from high fragility and footguns. I understand the desire to use the existing keys but better speed, security (both theoretical and implementation-wise) and smaller sizes are pretty compelling reasons.
Also as far as I know, BearSSL (maybe wolfcrypt too but I haven't looked into it) has the only one with somewhat usable RSA implementation without going for something even worse than OpenSSL. Since BearSSL is already in our sights it makes sense to use it for signatures anyway.
If the abstraction is going to be compatible with FIPS, the backend is pretty much guaranteed to be stuck with less sane libraries (libgcrypt, OpenSSL, NSS and wolfcrypt). Since Alpine isn't certified (and doesn't seem to want it actively), do the official repository signatures need to stick by its rules?
It should be fair for a FIPS system to not be complatible with the signatures of the official repository which doesn't aim to be FIPS compliant.
I also agree with the compile-time backend choice.
I am not sure if another level of indirection is needed or wanted with the
ops
vtables here. I'd like this to be build-time selection.
I normally used a vtable because I wasn't sure about the signing key rotation policy of Alpine and wanted avoid per-scheme functions for the same task. Not having cryptographic agility would be preferreable actually and I will revisit the code accordingly.
And I can try to address this ticket as well. But probably as an later item.
I have been tinkering with some basic abstractions with a similar style to the rest of apk_* if it helps with some basic ideas. The backend is currently some rough OpenSSL code though in the long term going with a NaCl-style library (Libsodium, Monocypher etc.) is probably for the best. Alongside with a simplified backend it also allows for smaller key storage with no PEM armor needed. (At the cost of rotating out RSA keys with Ed25519 for future use which shouldn't be too significant?)
I have only looked at the codebase for a little bit but a good chunk of the operations seem to revolve around:
There seems to be some abstraction (e.g. apk_pkey
, apk_checksum
's methods etc.) but in general they keep intermixing with OpenSSL specific code when interacting with them.