Implement ed255519 using openssl too #2922
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Ah, it seems to fail if build with --with-crypto=glib. Will look at it. |
alexlarsson
force-pushed
the
openssl-ed25519
branch
from
2a6ffe6
to
fb0afbb
Compare
|
The debian testing build is failing with: I wonder what this is about. I didn't really change that... |
alexlarsson
force-pushed
the
openssl-ed25519
branch
3 times, most recently
from
1c73a4d
to
4fb976c
Compare
|
Ok, got everything working. But I don't understand how the composefs test worked before? |
Yeah I must have broken it a bit ago and it's not a gating test. Mind splitting out that fix as a separate distinct PR? |
cgwalters
requested changes
Jul 7, 2023
There was a problem hiding this comment.
OK, awesome! My biggest question here is: Are the signatures from libsodium and openssl interoperable?
Ah wait this is triggering a dim memory...yes, from git grep --author=walters --grep=signature, I found 40d6f6b and if indeed that test is passing, I think we're good!
Yes, I tried it both ways. |
|
And, yes: |
alexlarsson
force-pushed
the
openssl-ed25519
branch
from
b8e1aa7
to
15ad234
Compare
|
OK nice work here, I think let's get #2923 in and then rebase this on top and merge. (Alternatively you could drop the overlapping fixes from the composefs fix from this PR, because that test isn't currently gating, but eh) |
cgwalters
reviewed
Jul 7, 2023
alexlarsson
force-pushed
the
openssl-ed25519
branch
from
15ad234
to
ffde01c
Compare
|
Feel free to rebase this when #2923 lands, should work then. |
This adds some defines for ed25519 key sizes and drops uses of the libsodium defines for these, as well as replacing sodium_bin2hex use with ot_bin2hex. Some code that wes optionally built before are now always built. The goal for this is to support both libsodium and openssl. Also fixes return value of _load_pk_from_stream(). It used to always return FALSE.
libsodium is used if configured to keep the old behaviour, but if it is not enabled, and openssl is used, then ed25519 is now supported.
alexlarsson
force-pushed
the
openssl-ed25519
branch
from
ffde01c
to
474c2b1
Compare
Wth? This build in previous CI runs... |
The checksum utils uses the crypto lib, but we're not explicitly linking to it. I think this is why the CI got this error when using openssl on debian, during ostree binary linking: /usr/bin/ld: ./.libs/libotutil.a(libotutil_la-ot-checksum-utils.o): undefined reference to symbol 'EVP_DigestInit_ex@@OPENSSL_3.0.0' /usr/bin/ld: /lib/x86_64-linux-gnu/libcrypto.so.3: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status
cgwalters
approved these changes
Jul 7, 2023
|
BTW nice work here! |
alexlarsson
added a commit
to alexlarsson/osbuild
that referenced
this pull request
Jul 11, 2023
This form of signatures has been (build-time-optionally) supported since ostree 2020.4 as an alternative to the old gpg signatures. With the current work on composefs[1] they are becomming more important, as they will allow verification of the commit (and thus the composefs image) during boot, giving us a full trusted boot chain all the way into the ostree userspace. Note: `ostree sign` used to require libsodium and was thus disabled in e.g. the Fedora build of ostree. However, recently[2] it is also supported with openssl, which will let it be more widely used. [1] ostreedev/ostree#2921 [2] ostreedev/ostree#2922
alexlarsson
added a commit
to alexlarsson/osbuild
that referenced
this pull request
Jul 11, 2023
This form of signatures has been (build-time-optionally) supported since ostree 2020.4 as an alternative to the old gpg signatures. With the current work on composefs[1] they are becomming more important, as they will allow verification of the commit (and thus the composefs image) during boot, giving us a full trusted boot chain all the way into the ostree userspace. Note: `ostree sign` used to require libsodium and was thus disabled in e.g. the Fedora build of ostree. However, recently[2] it is also supported with openssl, which will let it be more widely used. [1] ostreedev/ostree#2921 [2] ostreedev/ostree#2922
alexlarsson
added a commit
to alexlarsson/osbuild
that referenced
this pull request
Jul 11, 2023
This form of signatures has been (build-time-optionally) supported since ostree 2020.4 as an alternative to the old gpg signatures. With the current work on composefs[1] they are becomming more important, as they will allow verification of the commit (and thus the composefs image) during boot, giving us a full trusted boot chain all the way into the ostree userspace. Note: `ostree sign` used to require libsodium and was thus disabled in e.g. the Fedora build of ostree. However, recently[2] it is also supported with openssl, which will let it be more widely used. [1] ostreedev/ostree#2921 [2] ostreedev/ostree#2922
alexlarsson
added a commit
to alexlarsson/osbuild
that referenced
this pull request
Jul 11, 2023
This form of signatures has been (build-time-optionally) supported since ostree 2020.4 as an alternative to the old gpg signatures. With the current work on composefs[1] they are becomming more important, as they will allow verification of the commit (and thus the composefs image) during boot, giving us a full trusted boot chain all the way into the ostree userspace. Note: `ostree sign` used to require libsodium and was thus disabled in e.g. the Fedora build of ostree. However, recently[2] it is also supported with openssl, which will let it be more widely used. [1] ostreedev/ostree#2921 [2] ostreedev/ostree#2922
alexlarsson
added a commit
to alexlarsson/osbuild
that referenced
this pull request
Aug 16, 2023
This form of signatures has been (build-time-optionally) supported since ostree 2020.4 as an alternative to the old gpg signatures. With the current work on composefs[1] they are becomming more important, as they will allow verification of the commit (and thus the composefs image) during boot, giving us a full trusted boot chain all the way into the ostree userspace. Note: `ostree sign` used to require libsodium and was thus disabled in e.g. the Fedora build of ostree. However, recently[2] it is also supported with openssl, which will let it be more widely used. [1] ostreedev/ostree#2921 [2] ostreedev/ostree#2922
alexlarsson
added a commit
to alexlarsson/osbuild
that referenced
this pull request
Nov 13, 2023
This form of signatures has been (build-time-optionally) supported since ostree 2020.4 as an alternative to the old gpg signatures. With the current work on composefs[1] they are becomming more important, as they will allow verification of the commit (and thus the composefs image) during boot, giving us a full trusted boot chain all the way into the ostree userspace. Note: `ostree sign` used to require libsodium and was thus disabled in e.g. the Fedora build of ostree. However, recently[2] it is also supported with openssl, which will let it be more widely used. [1] ostreedev/ostree#2921 [2] ostreedev/ostree#2922
alexlarsson
added a commit
to alexlarsson/osbuild
that referenced
this pull request
Nov 13, 2023
This form of signatures has been (build-time-optionally) supported since ostree 2020.4 as an alternative to the old gpg signatures. With the current work on composefs[1] they are becomming more important, as they will allow verification of the commit (and thus the composefs image) during boot, giving us a full trusted boot chain all the way into the ostree userspace. Note: `ostree sign` used to require libsodium and was thus disabled in e.g. the Fedora build of ostree. However, recently[2] it is also supported with openssl, which will let it be more widely used. [1] ostreedev/ostree#2921 [2] ostreedev/ostree#2922
alexlarsson
added a commit
to alexlarsson/osbuild
that referenced
this pull request
Nov 13, 2023
This form of signatures has been (build-time-optionally) supported since ostree 2020.4 as an alternative to the old gpg signatures. With the current work on composefs[1] they are becomming more important, as they will allow verification of the commit (and thus the composefs image) during boot, giving us a full trusted boot chain all the way into the ostree userspace. Note: `ostree sign` used to require libsodium and was thus disabled in e.g. the Fedora build of ostree. However, recently[2] it is also supported with openssl, which will let it be more widely used. [1] ostreedev/ostree#2921 [2] ostreedev/ostree#2922
alexlarsson
added a commit
to alexlarsson/osbuild
that referenced
this pull request
Nov 13, 2023
This form of signatures has been (build-time-optionally) supported since ostree 2020.4 as an alternative to the old gpg signatures. With the current work on composefs[1] they are becomming more important, as they will allow verification of the commit (and thus the composefs image) during boot, giving us a full trusted boot chain all the way into the ostree userspace. Note: `ostree sign` used to require libsodium and was thus disabled in e.g. the Fedora build of ostree. However, recently[2] it is also supported with openssl, which will let it be more widely used. [1] ostreedev/ostree#2921 [2] ostreedev/ostree#2922
alexlarsson
added a commit
to osbuild/osbuild
that referenced
this pull request
Nov 14, 2023
This form of signatures has been (build-time-optionally) supported since ostree 2020.4 as an alternative to the old gpg signatures. With the current work on composefs[1] they are becomming more important, as they will allow verification of the commit (and thus the composefs image) during boot, giving us a full trusted boot chain all the way into the ostree userspace. Note: `ostree sign` used to require libsodium and was thus disabled in e.g. the Fedora build of ostree. However, recently[2] it is also supported with openssl, which will let it be more widely used. [1] ostreedev/ostree#2921 [2] ostreedev/ostree#2922
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds an openssl-based implementation to ostree-sign-ed25519.c which is used if libsodium was not manually configured.
The target usedcase for this is: #2921