Implement alternative semi-fixslice by peterdettman · Pull Request #195 · RustCrypto/block-ciphers

peterdettman · 2020-11-02T06:47:52Z

under cfg feature 'semi_fixslice'
reduces code size at small cost to performance

Alternative, slightly simpler variant described in the paper. I'm not sure if this is the ideal way to present the alternative, but it gets working code in place.

- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri · 2020-11-02T14:24:58Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

tarcieri · 2020-11-02T14:26:59Z

- inv_shift_rows_1(&mut rkeys[i..(i + 8)]);
- inv_shift_rows_2(&mut rkeys[(i + 8)..(i + 16)]);
- inv_shift_rows_3(&mut rkeys[(i + 16)..(i + 24)]);
+ #[cfg(feature = "semi_fixslice")]


It doesn't look like you have a semi_fixslice feature declared in Cargo.toml?
I'm also not sure how I feel about a "feature" making things slower.

Sorry, wasn't aware that was a thing. I can add it. As to making things slower, there is the already-existing example of the "no_unroll" feature (in the kuznyechik implementation) that makes the code smaller and slower.
Is it possible in rust to have a public feature like "small_code" that is translated internally in each algorithm to whatever local features make the code smaller?

I wish there were better way to hint at these sort of things in Rust, but unfortunately there aren't AFAIK.
The problem with using features to degrade performance is it no longer becomes possible for a dependency to request the faster implementation, since feature unification will mean anything that requests the smaller implementation overrides it.

peterdettman · 2020-11-02T15:51:43Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

Going by the size of the rlib files in target/release/deps, semi_fixslice reduces code size by about 15%. The performance difference is tiny on my x86_64 machine; an educated guess based on the paper and the code is that it would be ~4% slower on constrained 32-bit devices (even smaller performance loss on arm because of the barrel shifter).

tarcieri · 2020-11-02T16:03:56Z

It might be worth it, but it comes at a cost of more possible codepaths to test and upkeep/maintenance. I think there's also a lot bigger wins to be made in the short term here, like eliminating the decryption code for AES-CTR use.

Speaking of codepaths to test, can you edit .github/workflows/aes-soft.yml and add a line to test the feature in CI?

peterdettman · 2020-11-02T06:47:52Z

under cfg feature 'semi_fixslice'
reduces code size at small cost to performance

Alternative, slightly simpler variant described in the paper. I'm not sure if this is the ideal way to present the alternative, but it gets working code in place.

- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri · 2020-11-02T14:24:58Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

tarcieri · 2020-11-02T14:26:59Z

- inv_shift_rows_1(&mut rkeys[i..(i + 8)]);
- inv_shift_rows_2(&mut rkeys[(i + 8)..(i + 16)]);
- inv_shift_rows_3(&mut rkeys[(i + 16)..(i + 24)]);
+ #[cfg(feature = "semi_fixslice")]


It doesn't look like you have a semi_fixslice feature declared in Cargo.toml?
I'm also not sure how I feel about a "feature" making things slower.

Sorry, wasn't aware that was a thing. I can add it. As to making things slower, there is the already-existing example of the "no_unroll" feature (in the kuznyechik implementation) that makes the code smaller and slower.
Is it possible in rust to have a public feature like "small_code" that is translated internally in each algorithm to whatever local features make the code smaller?

I wish there were better way to hint at these sort of things in Rust, but unfortunately there aren't AFAIK.
The problem with using features to degrade performance is it no longer becomes possible for a dependency to request the faster implementation, since feature unification will mean anything that requests the smaller implementation overrides it.

peterdettman · 2020-11-02T15:51:43Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

Going by the size of the rlib files in target/release/deps, semi_fixslice reduces code size by about 15%. The performance difference is tiny on my x86_64 machine; an educated guess based on the paper and the code is that it would be ~4% slower on constrained 32-bit devices (even smaller performance loss on arm because of the barrel shifter).

tarcieri · 2020-11-02T16:03:56Z

It might be worth it, but it comes at a cost of more possible codepaths to test and upkeep/maintenance. I think there's also a lot bigger wins to be made in the short term here, like eliminating the decryption code for AES-CTR use.

Speaking of codepaths to test, can you edit .github/workflows/aes-soft.yml and add a line to test the feature in CI?

peterdettman · 2020-11-02T06:47:52Z

under cfg feature 'semi_fixslice'
reduces code size at small cost to performance

Alternative, slightly simpler variant described in the paper. I'm not sure if this is the ideal way to present the alternative, but it gets working code in place.

- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri · 2020-11-02T14:24:58Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

tarcieri · 2020-11-02T14:26:59Z

- inv_shift_rows_1(&mut rkeys[i..(i + 8)]);
- inv_shift_rows_2(&mut rkeys[(i + 8)..(i + 16)]);
- inv_shift_rows_3(&mut rkeys[(i + 16)..(i + 24)]);
+ #[cfg(feature = "semi_fixslice")]


It doesn't look like you have a semi_fixslice feature declared in Cargo.toml?
I'm also not sure how I feel about a "feature" making things slower.

Sorry, wasn't aware that was a thing. I can add it. As to making things slower, there is the already-existing example of the "no_unroll" feature (in the kuznyechik implementation) that makes the code smaller and slower.
Is it possible in rust to have a public feature like "small_code" that is translated internally in each algorithm to whatever local features make the code smaller?

I wish there were better way to hint at these sort of things in Rust, but unfortunately there aren't AFAIK.
The problem with using features to degrade performance is it no longer becomes possible for a dependency to request the faster implementation, since feature unification will mean anything that requests the smaller implementation overrides it.

peterdettman · 2020-11-02T15:51:43Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

Going by the size of the rlib files in target/release/deps, semi_fixslice reduces code size by about 15%. The performance difference is tiny on my x86_64 machine; an educated guess based on the paper and the code is that it would be ~4% slower on constrained 32-bit devices (even smaller performance loss on arm because of the barrel shifter).

tarcieri · 2020-11-02T16:03:56Z

It might be worth it, but it comes at a cost of more possible codepaths to test and upkeep/maintenance. I think there's also a lot bigger wins to be made in the short term here, like eliminating the decryption code for AES-CTR use.

Speaking of codepaths to test, can you edit .github/workflows/aes-soft.yml and add a line to test the feature in CI?

peterdettman · 2020-11-02T06:47:52Z

under cfg feature 'semi_fixslice'
reduces code size at small cost to performance

Alternative, slightly simpler variant described in the paper. I'm not sure if this is the ideal way to present the alternative, but it gets working code in place.

- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri · 2020-11-02T14:24:58Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

tarcieri · 2020-11-02T14:26:59Z

- inv_shift_rows_1(&mut rkeys[i..(i + 8)]);
- inv_shift_rows_2(&mut rkeys[(i + 8)..(i + 16)]);
- inv_shift_rows_3(&mut rkeys[(i + 16)..(i + 24)]);
+ #[cfg(feature = "semi_fixslice")]


It doesn't look like you have a semi_fixslice feature declared in Cargo.toml?
I'm also not sure how I feel about a "feature" making things slower.

Sorry, wasn't aware that was a thing. I can add it. As to making things slower, there is the already-existing example of the "no_unroll" feature (in the kuznyechik implementation) that makes the code smaller and slower.
Is it possible in rust to have a public feature like "small_code" that is translated internally in each algorithm to whatever local features make the code smaller?

I wish there were better way to hint at these sort of things in Rust, but unfortunately there aren't AFAIK.
The problem with using features to degrade performance is it no longer becomes possible for a dependency to request the faster implementation, since feature unification will mean anything that requests the smaller implementation overrides it.

peterdettman · 2020-11-02T15:51:43Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

Going by the size of the rlib files in target/release/deps, semi_fixslice reduces code size by about 15%. The performance difference is tiny on my x86_64 machine; an educated guess based on the paper and the code is that it would be ~4% slower on constrained 32-bit devices (even smaller performance loss on arm because of the barrel shifter).

tarcieri · 2020-11-02T16:03:56Z

It might be worth it, but it comes at a cost of more possible codepaths to test and upkeep/maintenance. I think there's also a lot bigger wins to be made in the short term here, like eliminating the decryption code for AES-CTR use.

Speaking of codepaths to test, can you edit .github/workflows/aes-soft.yml and add a line to test the feature in CI?

peterdettman · 2020-11-02T06:47:52Z

under cfg feature 'semi_fixslice'
reduces code size at small cost to performance

Alternative, slightly simpler variant described in the paper. I'm not sure if this is the ideal way to present the alternative, but it gets working code in place.

- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri · 2020-11-02T14:24:58Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

tarcieri · 2020-11-02T14:26:59Z

- inv_shift_rows_1(&mut rkeys[i..(i + 8)]);
- inv_shift_rows_2(&mut rkeys[(i + 8)..(i + 16)]);
- inv_shift_rows_3(&mut rkeys[(i + 16)..(i + 24)]);
+ #[cfg(feature = "semi_fixslice")]


It doesn't look like you have a semi_fixslice feature declared in Cargo.toml?
I'm also not sure how I feel about a "feature" making things slower.

Sorry, wasn't aware that was a thing. I can add it. As to making things slower, there is the already-existing example of the "no_unroll" feature (in the kuznyechik implementation) that makes the code smaller and slower.
Is it possible in rust to have a public feature like "small_code" that is translated internally in each algorithm to whatever local features make the code smaller?

I wish there were better way to hint at these sort of things in Rust, but unfortunately there aren't AFAIK.
The problem with using features to degrade performance is it no longer becomes possible for a dependency to request the faster implementation, since feature unification will mean anything that requests the smaller implementation overrides it.

peterdettman · 2020-11-02T15:51:43Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

Going by the size of the rlib files in target/release/deps, semi_fixslice reduces code size by about 15%. The performance difference is tiny on my x86_64 machine; an educated guess based on the paper and the code is that it would be ~4% slower on constrained 32-bit devices (even smaller performance loss on arm because of the barrel shifter).

tarcieri · 2020-11-02T16:03:56Z

It might be worth it, but it comes at a cost of more possible codepaths to test and upkeep/maintenance. I think there's also a lot bigger wins to be made in the short term here, like eliminating the decryption code for AES-CTR use.

Speaking of codepaths to test, can you edit .github/workflows/aes-soft.yml and add a line to test the feature in CI?

peterdettman · 2020-11-02T06:47:52Z

under cfg feature 'semi_fixslice'
reduces code size at small cost to performance

Alternative, slightly simpler variant described in the paper. I'm not sure if this is the ideal way to present the alternative, but it gets working code in place.

- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri · 2020-11-02T14:24:58Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

tarcieri · 2020-11-02T14:26:59Z

- inv_shift_rows_1(&mut rkeys[i..(i + 8)]);
- inv_shift_rows_2(&mut rkeys[(i + 8)..(i + 16)]);
- inv_shift_rows_3(&mut rkeys[(i + 16)..(i + 24)]);
+ #[cfg(feature = "semi_fixslice")]


It doesn't look like you have a semi_fixslice feature declared in Cargo.toml?
I'm also not sure how I feel about a "feature" making things slower.

Sorry, wasn't aware that was a thing. I can add it. As to making things slower, there is the already-existing example of the "no_unroll" feature (in the kuznyechik implementation) that makes the code smaller and slower.
Is it possible in rust to have a public feature like "small_code" that is translated internally in each algorithm to whatever local features make the code smaller?

I wish there were better way to hint at these sort of things in Rust, but unfortunately there aren't AFAIK.
The problem with using features to degrade performance is it no longer becomes possible for a dependency to request the faster implementation, since feature unification will mean anything that requests the smaller implementation overrides it.

peterdettman · 2020-11-02T15:51:43Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

Going by the size of the rlib files in target/release/deps, semi_fixslice reduces code size by about 15%. The performance difference is tiny on my x86_64 machine; an educated guess based on the paper and the code is that it would be ~4% slower on constrained 32-bit devices (even smaller performance loss on arm because of the barrel shifter).

tarcieri · 2020-11-02T16:03:56Z

It might be worth it, but it comes at a cost of more possible codepaths to test and upkeep/maintenance. I think there's also a lot bigger wins to be made in the short term here, like eliminating the decryption code for AES-CTR use.

Speaking of codepaths to test, can you edit .github/workflows/aes-soft.yml and add a line to test the feature in CI?

peterdettman · 2020-11-02T06:47:52Z

under cfg feature 'semi_fixslice'
reduces code size at small cost to performance

Alternative, slightly simpler variant described in the paper. I'm not sure if this is the ideal way to present the alternative, but it gets working code in place.

- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri · 2020-11-02T14:24:58Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

tarcieri · 2020-11-02T14:26:59Z

- inv_shift_rows_1(&mut rkeys[i..(i + 8)]);
- inv_shift_rows_2(&mut rkeys[(i + 8)..(i + 16)]);
- inv_shift_rows_3(&mut rkeys[(i + 16)..(i + 24)]);
+ #[cfg(feature = "semi_fixslice")]


It doesn't look like you have a semi_fixslice feature declared in Cargo.toml?
I'm also not sure how I feel about a "feature" making things slower.

Sorry, wasn't aware that was a thing. I can add it. As to making things slower, there is the already-existing example of the "no_unroll" feature (in the kuznyechik implementation) that makes the code smaller and slower.
Is it possible in rust to have a public feature like "small_code" that is translated internally in each algorithm to whatever local features make the code smaller?

I wish there were better way to hint at these sort of things in Rust, but unfortunately there aren't AFAIK.
The problem with using features to degrade performance is it no longer becomes possible for a dependency to request the faster implementation, since feature unification will mean anything that requests the smaller implementation overrides it.

peterdettman · 2020-11-02T15:51:43Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

Going by the size of the rlib files in target/release/deps, semi_fixslice reduces code size by about 15%. The performance difference is tiny on my x86_64 machine; an educated guess based on the paper and the code is that it would be ~4% slower on constrained 32-bit devices (even smaller performance loss on arm because of the barrel shifter).

tarcieri · 2020-11-02T16:03:56Z

It might be worth it, but it comes at a cost of more possible codepaths to test and upkeep/maintenance. I think there's also a lot bigger wins to be made in the short term here, like eliminating the decryption code for AES-CTR use.

Speaking of codepaths to test, can you edit .github/workflows/aes-soft.yml and add a line to test the feature in CI?

peterdettman · 2020-11-02T06:47:52Z

under cfg feature 'semi_fixslice'
reduces code size at small cost to performance

Alternative, slightly simpler variant described in the paper. I'm not sure if this is the ideal way to present the alternative, but it gets working code in place.

- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri · 2020-11-02T14:24:58Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

tarcieri · 2020-11-02T14:26:59Z

- inv_shift_rows_1(&mut rkeys[i..(i + 8)]);
- inv_shift_rows_2(&mut rkeys[(i + 8)..(i + 16)]);
- inv_shift_rows_3(&mut rkeys[(i + 16)..(i + 24)]);
+ #[cfg(feature = "semi_fixslice")]


It doesn't look like you have a semi_fixslice feature declared in Cargo.toml?
I'm also not sure how I feel about a "feature" making things slower.

Sorry, wasn't aware that was a thing. I can add it. As to making things slower, there is the already-existing example of the "no_unroll" feature (in the kuznyechik implementation) that makes the code smaller and slower.
Is it possible in rust to have a public feature like "small_code" that is translated internally in each algorithm to whatever local features make the code smaller?

I wish there were better way to hint at these sort of things in Rust, but unfortunately there aren't AFAIK.
The problem with using features to degrade performance is it no longer becomes possible for a dependency to request the faster implementation, since feature unification will mean anything that requests the smaller implementation overrides it.

peterdettman · 2020-11-02T15:51:43Z

I originally translated this as well but got rid of it as I wasn't really sure the meager code size benefits were actually worth it (or how much code size it actually saves you in compiled Rust)

Going by the size of the rlib files in target/release/deps, semi_fixslice reduces code size by about 15%. The performance difference is tiny on my x86_64 machine; an educated guess based on the paper and the code is that it would be ~4% slower on constrained 32-bit devices (even smaller performance loss on arm because of the barrel shifter).

tarcieri · 2020-11-02T16:03:56Z

It might be worth it, but it comes at a cost of more possible codepaths to test and upkeep/maintenance. I think there's also a lot bigger wins to be made in the short term here, like eliminating the decryption code for AES-CTR use.

Speaking of codepaths to test, can you edit .github/workflows/aes-soft.yml and add a line to test the feature in CI?

Implement alternative semi-fixslice
646ef33
- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri reviewed Nov 2, 2020
View reviewed changes

Add Cargo.toml feature 'semi_fixslice'
680d356

Add semi_fixslice CI tests
7bc419b

tarcieri merged commit 775ccbc into RustCrypto:masterNov 2, 2020

tarcieri mentioned this pull request Nov 16, 2020
aes-soft v0.6.4 #199
Merged

tarcieri mentioned this pull request May 10, 2021
aes: feature flags are not additive #245
Closed

Implement alternative semi-fixslice
646ef33
- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri reviewed Nov 2, 2020
View reviewed changes

Add Cargo.toml feature 'semi_fixslice'
680d356

Add semi_fixslice CI tests
7bc419b

tarcieri merged commit 775ccbc into RustCrypto:masterNov 2, 2020

tarcieri mentioned this pull request Nov 16, 2020
aes-soft v0.6.4 #199
Merged

tarcieri mentioned this pull request May 10, 2021
aes: feature flags are not additive #245
Closed

Implement alternative semi-fixslice
646ef33
- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri reviewed Nov 2, 2020
View reviewed changes

Add Cargo.toml feature 'semi_fixslice'
680d356

Add semi_fixslice CI tests
7bc419b

tarcieri merged commit 775ccbc into RustCrypto:masterNov 2, 2020

tarcieri mentioned this pull request Nov 16, 2020
aes-soft v0.6.4 #199
Merged

tarcieri mentioned this pull request May 10, 2021
aes: feature flags are not additive #245
Closed

Implement alternative semi-fixslice
646ef33
- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri reviewed Nov 2, 2020
View reviewed changes

Add Cargo.toml feature 'semi_fixslice'
680d356

Add semi_fixslice CI tests
7bc419b

tarcieri merged commit 775ccbc into RustCrypto:masterNov 2, 2020

tarcieri mentioned this pull request Nov 16, 2020
aes-soft v0.6.4 #199
Merged

tarcieri mentioned this pull request May 10, 2021
aes: feature flags are not additive #245
Closed

Implement alternative semi-fixslice
646ef33
- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri reviewed Nov 2, 2020
View reviewed changes

Add Cargo.toml feature 'semi_fixslice'
680d356

Add semi_fixslice CI tests
7bc419b

tarcieri merged commit 775ccbc into RustCrypto:masterNov 2, 2020

tarcieri mentioned this pull request Nov 16, 2020
aes-soft v0.6.4 #199
Merged

tarcieri mentioned this pull request May 10, 2021
aes: feature flags are not additive #245
Closed

Implement alternative semi-fixslice
646ef33
- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri reviewed Nov 2, 2020
View reviewed changes

Add Cargo.toml feature 'semi_fixslice'
680d356

Add semi_fixslice CI tests
7bc419b

tarcieri merged commit 775ccbc into RustCrypto:masterNov 2, 2020

tarcieri mentioned this pull request Nov 16, 2020
aes-soft v0.6.4 #199
Merged

tarcieri mentioned this pull request May 10, 2021
aes: feature flags are not additive #245
Closed

Implement alternative semi-fixslice
646ef33
- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri reviewed Nov 2, 2020
View reviewed changes

Add Cargo.toml feature 'semi_fixslice'
680d356

Add semi_fixslice CI tests
7bc419b

tarcieri merged commit 775ccbc into RustCrypto:masterNov 2, 2020

tarcieri mentioned this pull request Nov 16, 2020
aes-soft v0.6.4 #199
Merged

tarcieri mentioned this pull request May 10, 2021
aes: feature flags are not additive #245
Closed

Implement alternative semi-fixslice
646ef33
- under cfg feature 'semi_fixslice' - reduces code size at small cost to performance

tarcieri reviewed Nov 2, 2020
View reviewed changes

Add Cargo.toml feature 'semi_fixslice'
680d356

Add semi_fixslice CI tests
7bc419b

tarcieri merged commit 775ccbc into RustCrypto:masterNov 2, 2020

tarcieri mentioned this pull request Nov 16, 2020
aes-soft v0.6.4 #199
Merged

tarcieri mentioned this pull request May 10, 2021
aes: feature flags are not additive #245
Closed

Uh oh!

Conversation

peterdettman commented Nov 2, 2020

Uh oh!

tarcieri commented Nov 2, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tarcieriNov 2, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

peterdettman commented Nov 2, 2020

Uh oh!

tarcieri commented Nov 2, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

peterdettman commented Nov 2, 2020

Uh oh!

tarcieri commented Nov 2, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tarcieriNov 2, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

peterdettman commented Nov 2, 2020

Uh oh!

tarcieri commented Nov 2, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

peterdettman commented Nov 2, 2020

Uh oh!

tarcieri commented Nov 2, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tarcieriNov 2, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

peterdettman commented Nov 2, 2020

Uh oh!

tarcieri commented Nov 2, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

tarcieriNov 2, 2020•
edited
Loading

tarcieriNov 2, 2020•
edited
Loading

tarcieriNov 2, 2020•
edited
Loading

tarcieriNov 2, 2020•
edited
Loading

tarcieriNov 2, 2020•
edited
Loading