Create Algorithm Registry API #1601

tetsuo-cpp · 2024-01-18T11:00:34Z

Summary

As part of our work to support configurable crypto algorithms across the Sigstore stack, we've added a KnownSignatureAlgorithm enumeration to protobuf-specs to reflect what signature algorithms are part of the official Sigstore algorithm registry. This PR adds some helpers and APIs to make use of this registry in Sigstore services.

Release Note

Added GetAlgorithmDetails helper to access the key algorithm, hash algorithm and other algorithm-specific parameters for a given signature algorithm.
Added AlgorithmRegistryConfig API to check a public key and hash algorithm combination against a set of accepted signature algorithms.
Added FormatSignatureAlgorithmFlag and ParseSignatureAlgorithmFlag to convert the signature algorithm type to and from a string representation that can be used as a CLI parameter.

Documentation

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

tetsuo-cpp · 2024-01-18T11:00:56Z

I'm working on some unit tests now.

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

tetsuo-cpp · 2024-01-18T12:57:37Z

pkg/signature/algorithm_registry.go

+	return a.hashType == hashType
+}
+
+var algorithmDetails = []algorithmDetailsImpl{


I moved away from that design where I had an interface and an implementation for each signature algorithm as it was really doing anything for us. Each AlgorithmRegistryConfig now holds pointers to algorithms in this list.

tetsuo-cpp · 2024-01-18T12:59:06Z

pkg/signature/algorithm_registry.go

+	return fmt.Errorf("signing algorithm not permitted: %T, %s", key, hash)
+}
+
+// FormatSignatureAlgorithmFlag formats a v1.KnownSignatureAlgorithm to a string that conforms to the conventions of CLI


This CLI stuff isn't terribly efficient but I don't expect it to be on the hot path since this is just initialisation code.

pkg/signature/algorithm_registry.go

tetsuo-cpp · 2024-01-18T13:04:22Z

CC: @ret2libc @woodruffw @haydentherapper

pkg/signature/algorithm_registry.go

Co-authored-by: Riccardo Schirone <562321+ret2libc@users.noreply.github.com> Signed-off-by: William Woodruff <william@yossarian.net>

Signed-off-by: William Woodruff <william@trailofbits.com>

ret2libc · 2024-01-19T16:55:12Z

@tetsuo-cpp you can see https://github.com/trail-of-forks/cosign/compare/support-ed25519ph...trail-of-forks:cosign:signing-algorithm-flag?expand=1 on how I might be using the registry in cosign. Hope it helps us define a good API!

This reverts commit 9eec947. Signed-off-by: William Woodruff <william@trailofbits.com>

Signed-off-by: Riccardo Schirone <riccardo.schirone@trailofbits.com> Signed-off-by: William Woodruff <william@trailofbits.com>

woodruffw · 2024-01-19T20:12:02Z

(Force-pushed to fix the signoffs.)

pkg/signature/algorithm_registry.go

haydentherapper · 2024-01-19T22:26:55Z

pkg/signature/algorithm_registry.go

+}
+
+// IsAlgorithmPermitted checks whether a given public key/hash algorithm combination is permitted by a registry config.
+func (registryConfig AlgorithmRegistryConfig) IsAlgorithmPermitted(key crypto.PublicKey, hash crypto.Hash) bool {


How do you foresee this being used with KMS keys? Should the caller be required to inspect the KMS key for its key and hash (we have key, we're missing hash, but it's being implemented in #1426). Should each KMS provider has its own registry?(as a service, this would be a bit annoying to use, since you'd have to consult a registry of regstries)

I think it makes most sense for the calling code to inspect the KMS key and hash, and check against the registry to see whether it should use that key or not.

I don't think it makes sense for each KMS provider to own its own registry, but perhaps the kms.SignerVerifier API could take an optional AlgorithmRegistryConfig and do the checking there? But I'd lean towards not tangling the APIs together like that and just let the calling code compose these calls as required.

What are your thoughts?

That sounds good to me. Long-term I'd lean towards the proposal to take in a config, just to avoid each client having to reimplement this, but I don't think it's something that's blocking regardless, just thinking through how we'll handle users who provide their own KMS keys.

pkg/signature/algorithm_registry.go

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

pkg/signature/algorithm_registry.go

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

go.mod

haydentherapper · 2024-01-24T00:11:30Z

pkg/signature/algorithm_registry.go

+}
+
+// IsAlgorithmPermitted checks whether a given public key/hash algorithm combination is permitted by a registry config.
+func (registryConfig AlgorithmRegistryConfig) IsAlgorithmPermitted(key crypto.PublicKey, hash crypto.Hash) bool {


That sounds good to me. Long-term I'd lean towards the proposal to take in a config, just to avoid each client having to reimplement this, but I don't think it's something that's blocking regardless, just thinking through how we'll handle users who provide their own KMS keys.

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

…ry-api

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

haydentherapper

Overall LGTM, please take a look at the lint failure

haydentherapper · 2024-01-29T21:50:02Z

pkg/signature/algorithm_registry_test.go

+	if err != nil {
+		t.Errorf("unexpected error creating algorithm registry config: %v", err)
+	}
+


Can we also add a test for RSA keys being permitted?

It might be overkill, but ideally we'd have a test for every supported key type, to have maximum code coverage.

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

failure cases Signed-off-by: Alex Cameron <asc@tetsuo.sh>

pkg/signature/algorithm_registry.go

haydentherapper · 2024-01-30T00:17:47Z

@kommendorkapten Do you want to take a look at this PR? There's an open question of how this should interact with PublicKeyDetails (thread)

Co-authored-by: Hayden B <hblauzvern@google.com> Signed-off-by: Alex Cameron <asc@tetsuo.sh>

kommendorkapten · 2024-01-30T12:25:50Z

This is great 🚀
This is quite related to the existing PublicKeyDetails, which today is used when distributing the trust root, to indicate how to interpret and use public key material, e.g. the public key for Rekor.

I believe there is an overlap between KnownSignatureAlgorithm and PublicKeyDetails, and I fear this may become a bit complicated for clients to work with. How do we feel about merging them into PublicKeyDetails?

PublicKeyDetails captures the signature algorithm used (albeit a bit underspecified for RSA keys, but that can easily be fixed), which is exactly what KnownSignatureAlgorithm does.

The only differences I see is the naming, and that PublicKeyDetails also indicates the encoding of the public key material, but I would think that it wouldn't really matter, I would say that it's only RSA keys that in practice may have different encodings (PKCS vs PKIX).

One can argue that the two types might solve slightly different problems, but as the overlap is so big, I would feel better if they could be combined, otherwise the clients would need to translate between the two formats, which I feel is sub-optimal.

Thoughts?

tetsuo-cpp · 2024-01-30T13:57:47Z

The only differences I see is the naming, and that PublicKeyDetails also indicates the encoding of the public key material, but I would think that it wouldn't really matter, I would say that it's only RSA keys that in practice may have different encodings (PKCS vs PKIX).

Aren't the RSA values also missing the hash algorithm, or is that implied somehow? That was the main reason I didn't add to PublicKeyDetails (as well as the key encoding). It seemed to me that the KnownSignatureAlgorithm enum would be capturing a slightly different set of information than what's in PublicKeyDetails.

If it's fine to overwrite the values in PublicKeyDetails with what's in KnownSignatureAlgorithm (that is, if we can avoid distinguishing how the key is encoded as well as add hash functions and key sizes for each of the RSA options), then I don't see anything stopping us from merging the two.

kommendorkapten · 2024-01-30T14:06:25Z

Aren't the RSA values also missing the hash algorithm, or is that implied somehow?

I don't remember the reason we left the RSA values underspecified 🤔 , but adding new values with them in there would make no harm.

Yeah, adding the new values missing in PublicKeyDetails is preferable IMHO. The old RSA values can be marked as [deprecated = true]. I believe RSA are the only ones that needs updates, the EC types matches what's in KownSignatureAlgorithms (but only P256 is listed). I would also be tempted to mark deterministic ECDSA as deprecated, I don't think anyone is using that?

tetsuo-cpp · 2024-01-30T14:14:29Z

Yeah, adding the new values missing in PublicKeyDetails is preferable IMHO. The old RSA values can be marked as [deprecated = true]. I believe RSA are the only ones that needs updates, the EC types matches what's in KownSignatureAlgorithms (but only P256 is listed). I would also be tempted to mark deterministic ECDSA as deprecated, I don't think anyone is using that?

That seems reasonable.

I had another idea though: what do you think about marking the entire PublicKeyDetails enum as deprecated and then move any code using this enum to use KnownSignatureAlgorithms? That way, we can maintain backwards compatibility as you're suggesting without diverging from the algorithm registry markdown and having lots of deprecated options mixed in with legitimate ones in the short term.

kommendorkapten · 2024-01-30T14:21:07Z

I had another idea though: what do you think about marking the entire PublicKeyDetails enum as deprecated

My gut feeling is that this will be quite disruptive for the community, as this field is being used in quite a few places. And it would also require us to have mechanism of indicating the encoding of the key (especially for RSA keys). There are quite a few implementations out there already (Go, Java, JavaScript, Python, and some tooling for managing the trust root which depends on the pubplic key type).

without diverging from the algorithm registry markdown

Hm, why would the public key type diverge from that? Because of the added encoding info?

tetsuo-cpp · 2024-01-30T14:37:58Z

My gut feeling is that this will be quite disruptive for the community, as this field is being used in quite a few places. And it would also require us to have mechanism of indicating the encoding of the key (especially for RSA keys). There are quite a few implementations out there already (Go, Java, JavaScript, Python, and some tooling for managing the trust root which depends on the pubplic key type).

I think I understand. My reasoning was that if we're deprecating most of the existing values, it'll already be disruptive and will require modification to any code that reads/writes those enums. But there's probably some code where the enum gets passed around without operating on it which would recompile fine if we stick with PublicKeyDetails, whereas removing that enum will break that code. Is that what you mean?

Hm, why would the public key type diverge from that? Because of the added encoding info?

Yeah, I expect the number of values for RSA will double since we'll be duplicating them to include the encoding info.

kommendorkapten · 2024-01-30T15:11:13Z

recompile fine if we stick with PublicKeyDetails, whereas removing that enum will break that code. Is that what you mean?

Yeah, I would envision something like this:

enum PublicKeyDetails {
        PUBLIC_KEY_DETAILS_UNSPECIFIED = 0;
        // RSA
        PKCS1_RSA_PKCS1V5 = 1 [deprecated = true]; // See RFC8017
        PKCS1_RSA_PSS = 2 [deprecated = true]; // See RFC8017
        PKIX_RSA_PKCS1V5 = 3 [deprecated = true];
        PKIX_RSA_PSS = 4 [deprecated = true];
        PKIX_RSA_PKCS1_2048_SHA256 = 9;
        PKIX_RSA_PKCS1_3072_SHA256 = 10;
        PKIX_RSA_PKCS1_4096_SHA256 = 11;
       
        // ECDSA
        PKIX_ECDSA_P256_SHA_256 = 5; // See NIST FIPS 186-4
        PKIX_ECDSA_P256_SHA_384 = 12;
        PKIX_ECDSA_P256_SHA_521 = 13;        
        PKIX_ECDSA_P256_HMAC_SHA_256 = 6 [deprecated = true]; // See RFC6979
       
        // Ed 25519
        PKIX_ED25519 = 7; // See RFC8032
        PKIX_ED25519_PH = 8;
}

So there would be only additions for the new curves and more specified RSA ones. And as (at least to my knowledge) the currently most commonly used key-type is NIST P256, this wouldn't be disruptive, and we can let the deprecated RSA keys be there for a few releases to let any users of that update.

I think we can be prescriptive here about encoding and signature scheme for RSA, but curious to hear from e.g. @haydentherapper to minimize the duplication.

woodruffw · 2024-01-30T22:21:42Z

(Sorry, catching up here!)

@kommendorkapten's proposal looks reasonable to me -- it'd be nice to deduplicate here and reuse PublicKeyDetails as the registry enumeration, provided that doesn't cause issues for clients (I don't see why it would).

Two thoughts:

Specifying the full suite (i.e. PK type + hash) shouldn't be an issue from an encoding perspective -- there are standard X.509 AlgorithmIdentifiers for RSA+PSS and RSA+PKCS1v1.5 that encode hash algorithm choices. That being said, those identifiers don't encode public modulus length, so in practice there won't be any X.509 encoding difference between PKIX_RSA_PKCS1_2048_SHA256 and PKIX_RSA_PKCS1_3072_SHA256, etc. This may or may not matter; we may want to keep them as separate enum variants regardless 🙂
The PublicKeyDetails name is slightly misleading, since the enum now (fully) captures both the public key type and its signature parameter set. This is fine IMO (especially since some variants already do this, but I figure it's worth calling it).

kommendorkapten · 2024-01-31T08:33:23Z

That being said, those identifiers don't encode public modulus length, so in practice there won't be any X.509 encoding difference between PKIX_RSA_PKCS1_2048_SHA256 and PKIX_RSA_PKCS1_3072_SHA256, etc. This may or may not matter; we may want to keep them as separate enum variants regardless 🙂

I don't have any strong preferences against any of the options here I think. As the public key is part of the function to verify a key and hash, we could instead of matching against a set list only verify that the public modulus length is larger or equal than say 2048 (or compare against a set of lengths).

The PublicKeyDetails name is slightly misleading, since the enum now (fully) captures both the public key type and its signature parameter set.

Yes, the name may not be optimal, but I don't think it's that bad 😄

kommendorkapten · 2024-02-02T08:03:10Z

See sigstore/protobuf-specs#212 for PR on merge of PublicKeyDetails and KnownSignatureAlgorithms.

tetsuo-cpp · 2024-02-05T06:33:18Z

See sigstore/protobuf-specs#212 for PR on merge of PublicKeyDetails and KnownSignatureAlgorithms.

Nice work, thanks for that. Once a release is cut, I'll get this PR up to date.

haydentherapper

Overall LGTM. As a meta comment, my only reservation is it's hard to know if we've gotten the API right here without seeing this in use. I'm not really concerned though since I don't expect this API to be used outside of the agility work initially.

haydentherapper · 2024-02-15T21:41:01Z

go.mod

@@ -13,6 +13,7 @@ require (
 	github.com/pkg/browser v0.0.0-20210911075715-681adbf594b8
 	github.com/secure-systems-lab/go-securesystemslib v0.8.0
 	github.com/segmentio/ksuid v1.0.4
+	github.com/sigstore/protobuf-specs v0.3.0-beta.2


Can bump up now

Done. I also had to use PublicKeyDetails as KnownSignatureAlgorithm was removed with recent changes.

ret2libc · 2024-02-19T08:41:40Z

Overall LGTM. As a meta comment, my only reservation is it's hard to know if we've gotten the API right here without seeing this in use. I'm not really concerned though since I don't expect this API to be used outside of the agility work initially.

@haydentherapper you can see its use in other pending PRs like sigstore/rekor#1974 , sigstore/cosign#3497 , sigstore/fulcio#1517 (this last one might be outdated)

Signed-off-by: Riccardo Schirone <riccardo.schirone@trailofbits.com>

…ry-api

kommendorkapten · 2024-02-19T10:07:05Z

pkg/signature/algorithm_registry.go

+var algorithmDetails = []algorithmDetailsImpl{
+	{v1.PublicKeyDetails_PKIX_RSA_PKCS1V15_2048_SHA256, RSA, crypto.SHA256, RSAKeySize(2048), "rsa-sign-pkcs1-2048-sha256"},
+	{v1.PublicKeyDetails_PKIX_RSA_PKCS1V15_3072_SHA256, RSA, crypto.SHA256, RSAKeySize(3072), "rsa-sign-pkcs1-3072-sha256"},
+	{v1.PublicKeyDetails_PKIX_RSA_PKCS1V15_4096_SHA256, RSA, crypto.SHA256, RSAKeySize(4096), "rsa-sign-pkcs1-4096-sha256"},


I think we should add the RSA/PSS options here too.

See https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_common.proto#L74

We should also document we aren't handling the deprecated options, namely a PKCS1v1.5 encoded RSA key, preferring PKIX encoding.

…ry-api

tetsuo-cpp added 2 commits January 18, 2024 18:55

Create Algorithm Registry API

6b35218

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

Make lint happy

bccf24e

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

tetsuo-cpp changed the title ~~Create Algorithm Registry Config API~~ Create Algorithm Registry API Jan 18, 2024

Add some unit tests

66e3bb8

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

tetsuo-cpp commented Jan 18, 2024

View reviewed changes

ret2libc reviewed Jan 18, 2024

View reviewed changes

woodruffw and others added 2 commits January 18, 2024 10:26

Apply suggestions from code review

2425981

Co-authored-by: Riccardo Schirone <562321+ret2libc@users.noreply.github.com> Signed-off-by: William Woodruff <william@yossarian.net>

Make things as private as possible

1be7204

Signed-off-by: William Woodruff <william@trailofbits.com>

woodruffw force-pushed the alex/algorithm-registry-api branch from 9eec947 to 1be7204 Compare January 18, 2024 17:54

woodruffw force-pushed the alex/algorithm-registry-api branch from c244a81 to 5b727de Compare January 19, 2024 20:10

ret2libc added 2 commits January 19, 2024 15:11

Revert "Make things as private as possible"

b85db1b

This reverts commit 9eec947. Signed-off-by: William Woodruff <william@trailofbits.com>

Add HasAlgorithmDetails/ListPermittedAlgorithms/GetAlgorithmDetails

dfb835b

Signed-off-by: Riccardo Schirone <riccardo.schirone@trailofbits.com> Signed-off-by: William Woodruff <william@trailofbits.com>

woodruffw force-pushed the alex/algorithm-registry-api branch from 5b727de to dfb835b Compare January 19, 2024 20:11

haydentherapper reviewed Jan 19, 2024

View reviewed changes

tetsuo-cpp added 4 commits January 20, 2024 19:11

Replace panics with errors

12edb0f

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

Update unit tests

8a29bcf

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

Remove string pointer

1d74008

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

Add comments for algorithmDetailsImpl

021f385

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

tetsuo-cpp requested a review from haydentherapper January 23, 2024 13:30

ret2libc suggested changes Jan 23, 2024

View reviewed changes

pkg/signature/algorithm_registry.go Outdated Show resolved Hide resolved

pkg/signature/algorithm_registry.go Outdated Show resolved Hide resolved

ret2libc mentioned this pull request Jan 23, 2024

Added --client-signing-algorithms flag sigstore/rekor#1974

Open

Assume pointer types for ECDSA and RSA keys

a3d6a56

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

haydentherapper previously approved these changes Jan 24, 2024

View reviewed changes

haydentherapper requested a review from bobcallaway January 24, 2024 00:13

Use v0.3.0-beta.2 tag

c14bfce

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

tetsuo-cpp dismissed haydentherapper’s stale review via c14bfce January 24, 2024 04:50

tetsuo-cpp added 2 commits January 29, 2024 00:16

Merge remote-tracking branch 'origin/main' into alex/algorithm-regist…

4a8dfb1

…ry-api

Convert bytes to bits

d89eade

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

tetsuo-cpp dismissed haydentherapper’s stale review via d89eade January 29, 2024 05:59

haydentherapper reviewed Jan 29, 2024

View reviewed changes

tetsuo-cpp added 2 commits January 30, 2024 09:35

Fix lint

d1963e3

Signed-off-by: Alex Cameron <asc@tetsuo.sh>

Add test for RSA keys being permitted and flesh out some of the RSA

c7acffd

failure cases Signed-off-by: Alex Cameron <asc@tetsuo.sh>

tetsuo-cpp requested a review from haydentherapper January 29, 2024 22:43

haydentherapper reviewed Jan 30, 2024

View reviewed changes

pkg/signature/algorithm_registry.go Outdated Show resolved Hide resolved

Update pkg/signature/algorithm_registry.go

f6deded

Co-authored-by: Hayden B <hblauzvern@google.com> Signed-off-by: Alex Cameron <asc@tetsuo.sh>

haydentherapper previously approved these changes Feb 15, 2024

View reviewed changes

ret2libc dismissed haydentherapper’s stale review via d548633 February 19, 2024 09:04

Update to use PublicKeyDetails

e6f153b

Signed-off-by: Riccardo Schirone <riccardo.schirone@trailofbits.com>

ret2libc force-pushed the alex/algorithm-registry-api branch from d548633 to e6f153b Compare February 19, 2024 09:06

Merge remote-tracking branch 'origin/main' into alex/algorithm-regist…

536a041

…ry-api

kommendorkapten reviewed Feb 19, 2024

View reviewed changes

ret2libc added 2 commits February 29, 2024 11:03

Add RSA PSS options and add docs to algorithmDetails

328f212

Merge remote-tracking branch 'origin/main' into alex-algorithm-regist…

1adb4a6

…ry-api

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Create Algorithm Registry API #1601

Create Algorithm Registry API #1601

tetsuo-cpp commented Jan 18, 2024

tetsuo-cpp commented Jan 18, 2024

tetsuo-cpp Jan 18, 2024 •

edited

tetsuo-cpp Jan 18, 2024

tetsuo-cpp commented Jan 18, 2024

ret2libc commented Jan 19, 2024

woodruffw commented Jan 19, 2024

haydentherapper Jan 19, 2024

tetsuo-cpp Jan 20, 2024

haydentherapper Jan 24, 2024

haydentherapper Jan 24, 2024

haydentherapper left a comment

haydentherapper Jan 29, 2024

tetsuo-cpp Jan 29, 2024

haydentherapper commented Jan 30, 2024

kommendorkapten commented Jan 30, 2024

tetsuo-cpp commented Jan 30, 2024

kommendorkapten commented Jan 30, 2024

tetsuo-cpp commented Jan 30, 2024

kommendorkapten commented Jan 30, 2024

tetsuo-cpp commented Jan 30, 2024

kommendorkapten commented Jan 30, 2024

woodruffw commented Jan 30, 2024

kommendorkapten commented Jan 31, 2024

kommendorkapten commented Feb 2, 2024

tetsuo-cpp commented Feb 5, 2024

haydentherapper left a comment

haydentherapper Feb 15, 2024

ret2libc Feb 19, 2024

ret2libc commented Feb 19, 2024

kommendorkapten Feb 19, 2024

kommendorkapten Feb 19, 2024

haydentherapper Feb 20, 2024

ret2libc Feb 29, 2024

Create Algorithm Registry API #1601

Are you sure you want to change the base?

Create Algorithm Registry API #1601

Conversation

tetsuo-cpp commented Jan 18, 2024

Summary

Release Note

Documentation

tetsuo-cpp commented Jan 18, 2024

tetsuo-cpp Jan 18, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tetsuo-cpp commented Jan 18, 2024

ret2libc commented Jan 19, 2024

woodruffw commented Jan 19, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

haydentherapper left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

haydentherapper commented Jan 30, 2024

kommendorkapten commented Jan 30, 2024

tetsuo-cpp commented Jan 30, 2024

kommendorkapten commented Jan 30, 2024

tetsuo-cpp commented Jan 30, 2024

kommendorkapten commented Jan 30, 2024

tetsuo-cpp commented Jan 30, 2024

kommendorkapten commented Jan 30, 2024

woodruffw commented Jan 30, 2024

kommendorkapten commented Jan 31, 2024

kommendorkapten commented Feb 2, 2024

tetsuo-cpp commented Feb 5, 2024

haydentherapper left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ret2libc commented Feb 19, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tetsuo-cpp Jan 18, 2024 •

edited