Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix 32 bit support, add i686-unknown-linux-gnu CI target #113

Merged
merged 3 commits into from
Jul 5, 2023
Merged

fix 32 bit support, add i686-unknown-linux-gnu CI target #113

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
cfa1281
ci: add a 32bit target build w/ cross.
cpu Jul 5, 2023
735479c
der: fix DER max size constants for 32bit targets.
cpu Jul 5, 2023
d4aa00a
cargo: bump version to 0.101.1
cpu Jul 5, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions .github/workflows/ci.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -188,6 +188,17 @@ jobs:
toolchain: 1.57.0
- run: cargo check --lib --all-features

cross:
cpu marked this conversation as resolved.
Show resolved Hide resolved
name: Check cross compilation targets
runs-on: ubuntu-20.04
steps:
- uses: actions/checkout@v3
with:
persist-credentials: false
- uses: dtolnay/rust-toolchain@nightly
- run: cargo install cross
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: This seems to add about a minute to the CI runtime. Do you think its worth caching the install or using cargo-binstall for a pre-compiled version?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was hesitant to add any 3rd party actions since I think the project has taken a pretty conservative stance on those in the past.

I'm not familiar with cargo-binstall but it does sound interesting. Maybe we could consider the speed optimizations in a follow-up once the breakage is addressed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like https://github.com/marketplace/actions/install-development-tools would maybe be the best way to integrate (?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "is this secure" part of the FAQ (https://github.com/cargo-bins/cargo-binstall#faq) gives me some pause :-/

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Their description doesn't seem horribly problematic (they go from crates.io -> GitHub), but its probably not worth the 1 minute of CI time then if we're both slightly hesitant. I was hoping there was a more clear answer for pre-compiled binaries.

- run: cross build --target i686-unknown-linux-gnu

coverage:
runs-on: ubuntu-20.04
steps:
Expand Down
2 changes: 1 addition & 1 deletion Cargo.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ license = "ISC"
name = "rustls-webpki"
readme = "README.md"
repository = "https://github.com/rustls/webpki"
version = "0.101.0"
version = "0.101.1"

include = [
"Cargo.toml",
Expand Down
8 changes: 4 additions & 4 deletions src/der.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -225,25 +225,25 @@ const SHORT_FORM_LEN_MAX: u8 = 128;
const LONG_FORM_LEN_ONE_BYTE: u8 = 0x81;

// Maximum size that can be expressed in a one byte long form len.
const LONG_FORM_LEN_ONE_BYTE_MAX: usize = (1 << 8) - 1;
const LONG_FORM_LEN_ONE_BYTE_MAX: usize = 0xff;

// Leading octet for long definite form DER length expressed in subsequent two bytes.
const LONG_FORM_LEN_TWO_BYTES: u8 = 0x82;

// Maximum size that can be expressed in a two byte long form len.
const LONG_FORM_LEN_TWO_BYTES_MAX: usize = (1 << (8 * 2)) - 1;
const LONG_FORM_LEN_TWO_BYTES_MAX: usize = 0xff_ff;

// Leading octet for long definite form DER length expressed in subsequent three bytes.
const LONG_FORM_LEN_THREE_BYTES: u8 = 0x83;

// Maximum size that can be expressed in a three byte long form len.
const LONG_FORM_LEN_THREE_BYTES_MAX: usize = (1 << (8 * 3)) - 1;
const LONG_FORM_LEN_THREE_BYTES_MAX: usize = 0xff_ff_ff;

// Leading octet for long definite form DER length expressed in subsequent four bytes.
const LONG_FORM_LEN_FOUR_BYTES: u8 = 0x84;

// Maximum size that can be expressed in a four byte long form der len.
const LONG_FORM_LEN_FOUR_BYTES_MAX: usize = (1 << (8 * 4)) - 1;
const LONG_FORM_LEN_FOUR_BYTES_MAX: usize = 0xff_ff_ff_ff;

// TODO: investigate taking decoder as a reference to reduce generated code
// size.
Expand Down