profile
viewpoint
Erich Gubler ErichDonGubler NZXT Orem, UT Dedicated to software that humans love. Experienced Rustacean and proud of it.

ErichDonGubler/adhesion-rs 46

D-inspired contract programming in Rust using macros

ErichDonGubler/cargo-script 2

Cargo script subcommand

ErichDonGubler/CraftBukkit 1

The Minecraft Server Mod API Implementation

ErichDonGubler/.sublime-user 0

Configuration repo for Sublime Text

ErichDonGubler/archivist 0

(WIP) Tooling to write the journal of your dreams

startedsonos/ffi-convert-rs

started time in 7 hours

startedrust-analyzer/ungrammar

started time in 14 hours

startedkevinmehall/codemap-diagnostic

started time in a day

startedunicode-org/icu4x

started time in 2 days

pull request commentnot-yet-awesome-rust/not-yet-awesome-rust

Update README to include new game dev projects

Thanks for your first contribution! Excited to have you here. :)

jeremyarde

comment created time in 2 days

push eventnot-yet-awesome-rust/not-yet-awesome-rust

Jeremy

commit sha 951b8f9ba01241af838e07534d4cac9dbe2bf224

Update README to include new game dev projects

view details

push time in 2 days

PR merged not-yet-awesome-rust/not-yet-awesome-rust

Update README to include new game dev projects

Adding some new game dev projects under Game development section

+2 -0

0 comment

1 changed file

jeremyarde

pr closed time in 2 days

startedEmbarkStudios/rust-gpu

started time in 3 days

issue commentgetzola/zola

“Smart” typographic punctuation

“Broken” is the wrong word here. It would cause wrong punctuation in most languages, that’s all.

I guess I use "breakage" in this context because the behavior in question (how content is generated/processed) seems fundamental enough to the function of an SSG that it can/should be considered part of its correctness.

I'm going to assume your concern is abstract (which is fine!). I think it's valid, and I hope it doesn't seem like the validity of your concern is in question. That said, getting concrete cases where smart punctuation might adversely affect users will likely be very beneficial in the discussion you were trying to motivate in how smart punctuation should be integrated, and that's why I wanted to drive the elaboration of those cases.

wezm

comment created time in 3 days

startedDarksonn/newton-riemann

started time in 3 days

issue commentgetzola/zola

“Smart” typographic punctuation

Well, either all languages must be supported or Zola needs to skip all non-English content files - or else the punctuation will be wrong.

You're making this same assertion that something will break, and that's what I'm trying to dive into -- is this an abstract concern for you, or do you have specific cases in mind where content may be broken?

wezm

comment created time in 3 days

issue commentgetzola/zola

“Smart” typographic punctuation

One of the problems I can see with this is that this partially breaks full i18n support. For example, „German quotation“ is not quite the same thing as “U.S. quotation”.

@dertuxmalwieder: I'm confused. The suggested changes here include a processing step to convert "text" into “text”, but AFAICT the only flow currently available for getting the German punctuation you reference via Gutenberg is just using „text” in your content source directly. This means that the German punctuation flow shouldn't change. Am I misunderstanding something?

wezm

comment created time in 3 days

push eventerichdongubler-dotfiles/install

Erich Gubler

commit sha dec0ce1e13679ffd74bd711bf50cc5a903fb65be

doc(windows): add comment noting intent for the `winaero-tweaker` package

view details

Erich Gubler

commit sha 5164e34ae076f58328e10b8cb2a8324d8471b99b

feat(windows): add some more standard tools from the `rust` dotfiles repo here

view details

Erich Gubler

commit sha 151680f93f43ce44051e674dad22f0b0379cd527

refactor(windows): alphabetize `fun` packages

view details

push time in 5 days

push eventerichdongubler-dotfiles/install

Erich Gubler

commit sha 2a618af92e519d9b96cf241444101b3bde84eeee

refactor(windows)!: `mv msys2-install.bat installer-windows-msys2.bat`

view details

Erich Gubler

commit sha 69cf33c1bb35b154533b3a5dff399cfa8924b52a

refactor(windows): alphabetize `base` package list

view details

Erich Gubler

commit sha 6b3598c1adab62012d2ef0d8e90d6d479bba0ee3

doc(windows): add commnet noting intent for the `winaero-tweaker` package

view details

Erich Gubler

commit sha 08697b6b0419533d2ab87f199fbf3c5fdfab2a5f

feat(windows): add some more standard tools from the `rust` dotfiles repo here

view details

Erich Gubler

commit sha 5e3dddaed42db9a8e7450236adcaa1b8e7007bd7

refactor(windows): alphabetize `fun` packages

view details

push time in 5 days

push eventerichdongubler-dotfiles/install

Erich Gubler

commit sha a22e8ff10567a0d8b3b571f0425464785a471077

refactor(windows): alphabetize `base` package list

view details

Erich Gubler

commit sha 16e31b53e757a3e142941c6a206f3d19ec5a4907

doc(windows): add commnet noting intent for the `winaero-tweaker` package

view details

Erich Gubler

commit sha 770998abbcd2875e6a226509211865d85592ff76

feat(windows): add some more standard tools from the `rust` dotfiles repo here

view details

Erich Gubler

commit sha ed0f640b3470cced8ffdb51d79717ebf7e309599

refactor(windows): alphabetize `fun` packages

view details

push time in 5 days

pull request commentEmbarkStudios/cargo-deny

Prepare release

Is there anything left for this release to be published? It'd be awfully nice for us at @NZXTCorp, since we use cargo-deny as part of the strict CI checking we do, and upgrading to Rust 1.47.0 in our toolchain is currently waiting on this (even with the proposed workaround that uses rev specifiers -- git sources aren't something we want to change right now).

Side note: looks like this obviates https://github.com/EmbarkStudios/cargo-deny/pull/293?

Thanks for your work on this!

Jake-Shadle

comment created time in 5 days

startedrune-rs/rune

started time in 5 days

startedgithub/docs

started time in 6 days

startedmintty/wsltty

started time in 7 days

issue commentbriansmith/ring

spin-rs no longer maintained (dependency)

I filed a PR some time ago updating ring to use conquer-once -- but I can see why it would be obviated by spin-rs becoming maintained again. Feel free to close https://github.com/briansmith/ring/pull/1053 if it doesn't make sense anymore.

bluejekyll

comment created time in 7 days

PR opened vivint-smarthome/opentelemetry-stackdriver

fix: `docs.rs` builds breaking

Implements the suggested fix specified for https://github.com/vivint-smarthome/opentelemetry-stackdriver/issues/8. My suggestion for testing this would be to use cargo publish --allow-dirty with the version in Cargo.toml marked as pre-release , i.e., 0.6.1-alpha.0.

+1 -0

0 comment

1 changed file

pr created time in 9 days

create barnchErichDonGubler/opentelemetry-stackdriver

branch : fix-docs.rs-builds

created branch time in 9 days

issue openedvivint-smarthome/opentelemetry-stackdriver

`docs.rs` builds be broke, yo

Enjoying an opportunity to be informal with the title here, since I know folks...but feel free to change it. 👍

Currently, docs.rs builds for this repo fail; pulling out the relevant error snippet:

[INFO] [stderr] error: failed to run custom build command for `opentelemetry-stackdriver v0.6.0 (/opt/rustwide/workdir)`
[INFO] [stderr] 
[INFO] [stderr] Caused by:
[INFO] [stderr]   process didn't exit successfully: `/opt/rustwide/target/debug/build/opentelemetry-stackdriver-5bb9eeda67370cd7/build-script-build` (exit code: 101)
[INFO] [stderr] --- stdout
[INFO] [stderr] out: Output { status: ExitStatus(ExitStatus(256)), stdout: "", stderr: "error: \'rustfmt\' is not installed for the toolchain \'nightly-x86_64-unknown-linux-gnu\'\nTo install, run `rustup component add rustfmt --toolchain nightly-x86_64-unknown-linux-gnu`\n" }

This is because the current build.rs in master attempts to run rustfmt as part of the default behavior for tonic-build with default features enabled:

https://github.com/vivint-smarthome/opentelemetry-stackdriver/blob/52d242073e04091b3b3621f18e66fde9f6e719af/build.rs#L2-L13

...and docs.rs does not include rustfmt in its Rust toolchain installation (justifiably so, since it probably shouldn't have any interesting in mutating code it builds docs for).

docs.rs Build page suggests that build.rs scripts use the DOCS_RS runtime variable:

To recognize Docs.rs from build.rs files, you can test for the environment variable DOCS_RS, e.g.:

if let Ok(_) = std::env::var("DOCS_RS") {
    // ... your code here ...
}

This could also be handled by separating the generation of code from build.rs, pushing the responsibility to developers, and having a CI check for up-to-date codegen. There can be good trade-offs with this, but methinks that that decision can and should be separate from the easy resolution above.

created time in 9 days

push eventerichdongubler-dotfiles/base

Erich Gubler

commit sha 18b37e282104834b8be1a2491cc82fe794fcbd41

feat: add `ckt` alias for `git`

view details

Erich Gubler

commit sha 952dbdec48d2b0c77c5af5a6d458c0961f5c336c

test: add `user.sign = true` for `git`

view details

Erich Gubler

commit sha f9bbfbea053aa5362cbf820c40422dc7747f96f8

fix: tweak `uplog` to use `git pl --all` (broken by previous commit, oops)

view details

Erich Gubler

commit sha 6ef63bd1edb3be054150f392160799697456d62d

feat(git): add `delta` pager configuration

view details

Erich Gubler

commit sha e15dbbf5af0829a6870f521f9f8118c0184390ef

feat(git): re-implement `git-ls-branches` with `git branch --format`

view details

Erich Gubler

commit sha 8aa6852635c3a2e631f98248a5fb3d78f84dc55d

feat(git): add `canpf` alias

view details

Erich Gubler

commit sha ecf438b375d8ee857a31b7d64e6c7e5437d986ec

fix(git): double-quote forwarded args for `up` alias

view details

Erich Gubler

commit sha 65fdec3b13e419ee56c2661ed697ff4357871a8b

fix(git)!: trade `root` alias for `show-root` alias

view details

push time in 12 days

pull request commentbriansmith/ring

Move from `spin` to `conquer-once`

@kellpossible: I've asked in upstream spin for clarification around the current maintainership of the project.

ErichDonGubler

comment created time in 16 days

issue commentmvdnes/spin-rs

Releasing a new version

Does this mean that RUSTSEC-2019-0031, which states this project is unmaintained, is invalid? I've been pinged on a PR I have that resolves that advisory for ring, where the 0.6.0 release was noted.

zesterer

comment created time in 16 days

startedpipxproject/pipx

started time in 16 days

startedandrewhickman/fs-err

started time in 16 days

create barnchNZXTCorp/neon

branch : main

created branch time in 17 days

startedpikapkg/snowpack

started time in 19 days

issue commentrust-lang/rust

Tracking issue for `ops::Try` (`try_trait` feature)

Forgive me if I missed it - why doesnt NoneError impl std::error::Error? This makes it useless for any functions returning Box<dyn Error> or similar.

Not an expert here, but I can see significant problems with trying to come up with a useful error message for "something was None and you expected it to be Some" (which is basically what you'd be gaining here -- some diagnostic message). In my experience, it has always made most sense to use the Option::ok_or_else combinator to use another error type instead, because as the calling code I generally have much better context to give anyways.

scottmcm

comment created time in 21 days

startedgnebbia/kb

started time in 23 days

startedsdushantha/tmpmail

started time in 23 days

create barnchmindv0rtex/eclair

branch : erich/macros-end-the-world-yay

created branch time in 23 days

issue commentsafing/portmaster

Portmaster makes networking slow

I just barely found this issue after a couple of frustrating weeks debugging my entire Internet connection at home, and I discovered this issue! I was a dolt and installed PortMaster without taking time to configure it (because I'd forgotten to play with it, and that I'd installed it), and I'm having the same symptoms as OP on Windows 10 (version 1909, build 18363.1082 -- relatively recent). My connection, which is normally ~2 MB/s on Ethernet, goes down to ~200 KB/s when things ARE downloading...but often I'll get zero throughput for periods of minutes at a time, making it impossible to have use things like conferencing technologies. After finally deciding to try Safe Mode with Networking, I audited the software on my machine and did a prompt facepalm after realizing this was installed at about the time I started having issues.

So, as with OP's case indicated by @dhaavi, it seems that I also had no non-default configuration for PortMaster on my machine.

northys

comment created time in 24 days

startedKaiJewson/inline-proc

started time in a month

startedKaiJewson/inline-proc

started time in a month

startedkellpossible/sentry-eyre

started time in a month

pull request commentJelteF/derive_more

[WIP] Implement proof-of-concept of an enum "affix"

@JelteF: After using this in production for some time, I want to submit that an affix key (as originally proposed in the OP I wrote) was probably the right design in the first place. A year after this gets merged, I came back to use a top-level enum format, something of the form:

use derive_more::Display;

#[derive(Debug, Display)]
#[display(fmt = "{:?}", self)]
enum Enum {
    Variant1,
    // ...
}

...but was confused by the diagnostic given (which I've filed a PR for) about a single fmt needing a single argument. It was only after examining source that I remembered that a top-level #[display(fmt = ..., ...)] on an enum uses an "affix mode". It's not very clear that suddenly expectations have changed, and it also makes the (somewhat intuitive, I think) case I was trying to implement above impossible without just manually impling the desired std::fmt trait again. Furthermore, I think it makes much more sense to prefer the above behavior for an outer enum fmt string, since that's much closer to what is already possible for

I'll filed a new issue proposing a breaking change for this use case with the above information, so let's continue discussion there.

ErichDonGubler

comment created time in a month

pull request commentJelteF/derive_more

`Display`: test that we can use `self` at the top level

Thanks for your PRs! Please rebase with master

❤️ Rebased!

ErichDonGubler

comment created time in a month

push eventErichDonGubler/derive_more

Erich Gubler

commit sha 39088967ba71d8e5d936c9689659dbbf74ce38d8

docs: fix diagnostics for affix spec usage on `enum`s (#140)

view details

Erich Gubler

commit sha d3904ad1d13d0f1a3c183e11896019686cd49e74

test: `display`: add case forwarding `self` of a `struct` to `Debug` impl

view details

Erich Gubler

commit sha e4dd06a08c4d49025049de54e378317e1c115b7c

feat!: move top-level `enum` `display` functionality to use `affix` key instead of `fmt`

view details

Erich Gubler

commit sha 89d5ad4a5c03bf28ed91dd12ae927c0026247291

WIP: feat: inheriting `fmt` at top-level of `enum`s for `Display`-like derives

view details

push time in a month

push eventErichDonGubler/derive_more

Erich Gubler

commit sha 39088967ba71d8e5d936c9689659dbbf74ce38d8

docs: fix diagnostics for affix spec usage on `enum`s (#140)

view details

Erich Gubler

commit sha d3904ad1d13d0f1a3c183e11896019686cd49e74

test: `display`: add case forwarding `self` of a `struct` to `Debug` impl

view details

push time in a month

delete branch ErichDonGubler/derive_more

delete branch : enum-affix-diagnostics

delete time in a month

PR opened JelteF/derive_more

WIP: Distinguish top-level enum `fmt` from `affix`

Fixes https://github.com/JelteF/derive_more/issues/142 by implementing the solution proposed in the OP. Once the proposal is validated, I'll fill in this PR with more details and polish it up for review.


Things to do before merge:

  • [ ] Soft dep on https://github.com/JelteF/derive_more/pull/141.
+21 -3

0 comment

2 changed files

pr created time in a month

issue openedJelteF/derive_more

`affix` is confusing with outer-level `enum` display formatting

Currently, when one uses a top-level display attribute for the Display derive on an enum, it switches to an affix mode that defines the enum's overall format and expects, at most, a single placeholder where inner variant display logic can print into:

#[derive(Display)]
#[display(fmt = "Prefix {} Suffix")] // at most 1 placeholder allowed here
enum Enum {
    #[display(fmt ="value")] // prints "Prefix value Suffix"
    Variant1,
    // ...
}

However, there's a few problems with this current behavior:

  • It's REALLY surprising to discover that fmt works rather differently than anywhere else here. It's not obvious why formatting should be different here, and there's no "obvious" signal that behavior is different. I feel qualified to say this since I implemented this behavior myself a year ago, and still was confused after reading diagnostics until I remembered what I had implemented.
  • Affix formatting defined this way is currently all-or-nothing. Once the design of the Display impl requires using a specific format some of the time,

I think that we can do better here. There are enough surprises with the current behavior that I think exploring alternatives is warranted. Here's what we stand to gain:

  • We can develop an API that operates as similarly to variant-level formatting as possible, which makes the design more coherent.
  • Because derive_more inhabits the same ecosystem as other crates that do Display deriving with rather different approaches, we could possibly try to find a top-level enum formatting option that is also consistent with those approaches (and play a bit better with other crates conceptually). In a second, I'll propose something similar to what thiserror, an error crate with facilities for deriving Display, currently does.

So, here's my proposal:

  • The current affix-oriented behavior should be moved to an affix attribute key, and (this) new behavior will be defined for fmt instead.

  • Re-define the fmt spec at the top level of an enum to be the default printing logic for an enum's variants that can be overridden by a more specific fmt rule. An overridable default has basis in some prior art; thiserror::Error treats top-level enum format specifiers as the "default" message (motivating issue, current relevant upstream master code at time of writing):

    use thiserror::Error;
    #[derive(Debug, Error)]
    #[error("error")]
    enum Enum {
        A, // displays "error"
        #[error("b")]
        B, // displays "b"
    }
    
  • Disallow affix and fmt to be used together at the same time for the time being, since that's a lot of open design space that doesn't need to be handled right this second.

To concretely translate my above suggestions into code:

use derive_more::Display;

// Using affixes at the top level of an `enum` is the same as before, except we
// use an `affix` key in the `display` attribute instead of `fmt`.
#[derive(Display)]
#[display(affix = "<{}>")]
enum UsesAffix {
    #[display(fmt = "a")]
    A, // prints "<a>"
    #[display(fmt = "b")]
    B, // prints "<b>"

	// This makes no sense and is still disallowed.
	// #[display(affix = ...)]
	// C,

    // ...
}

// A top-level `display(fmt = ..., ...)` now is:
//
// * Just like variant-level `display` attributes in that it uses formatting
//     args as usual. Only `self` is bound in arguments' context, of course.
// * Overridable by a variant-level `display` attribute.
//
// One motivating example for this is to just use `Debug` printing
// by default unless we happen to have something better.
#[derive(Display)]
#[format(fmt = "{:?}", self)]
enum DisplayDefaultsToDebug {
	A, // prints "A"
	#[display(fmt = "Display B")]
	B, // prints "Display B"
}

created time in a month

PR opened JelteF/derive_more

`Display`: test that we can use `self` at the top level

Currently, documentation for Display-like derives states:

The variables available in the arguments is self and each member of the variant, with members of tuple structs being named with a leading underscore and their index, i.e. _0, _1, _2, etc.

...but this isn't tested anywhere. This PR adds this coverage.


Checklist:

  • [ ] Merge soft dep (base) on #140.
+8 -2

0 comment

2 changed files

pr created time in a month

create barnchErichDonGubler/derive_more

branch : test-for-self-in-display

created branch time in a month

create barnchErichDonGubler/derive_more

branch : enum-affix-diagnostics

created branch time in a month

fork ErichDonGubler/derive_more

Some more derive(Trait) options

fork in a month

PR opened quebin31/muso

M4{A,V,P} support

Hey there! Decided to try my hand integrating mp4ameta into metadata.rs, and it turned out to be fairly easy! Thanks for making this -- this project let me easily determine the holes a faulty solo backup in my music store left in my now securely backed up music collection out of ~5k items, and I'm super grateful. I hope this is something I can give back to show gratitude so more people can get the support they need for this interesting project!

Things before this is ready for review/merge:

  • [ ] Tests tests tests.
+70 -1

0 comment

3 changed files

pr created time in a month

startedgiovanniberti/robusta

started time in a month

startedContractBridge/cardpack.rs

started time in a month

starteddocker/cli

started time in a month

startedigrigorik/videospeed

started time in a month

started0xd4d/iced

started time in a month

push eventErichDonGubler/muso

Erich Gubler

commit sha fcd6fd5d4b29712e6ea75536852c3c4760c66508

WIP: feat: add `m4{a,p}` support The actual desired functionality is probably all here, but tests are lacking and should definitely be brought up to par with the rest of the media formats.

view details

push time in a month

push eventErichDonGubler/muso

Erich Gubler

commit sha af321dc5e8abb69116a6550af4e2a857db90dba0

docs: `metadata.rs`: add comments about `magic_bytes` length

view details

Erich Gubler

commit sha 56117fcab3754f377b9b138167253b3cb9bc04fa

WIP: feat: add `m4{a,p}` support The actual desired functionality is probably all here, but tests are lacking and should definitely be brought up to par with the rest of the media formats.

view details

push time in a month

create barnchErichDonGubler/muso

branch : m4a

created branch time in a month

fork ErichDonGubler/muso

muso: music sorter

fork in a month

push eventErichDonGubler/docs-next

Erich Gubler

commit sha cc4741aa2aabf4de828354f927aea0f540148a93

fix: `introduction.md`: `notable-new-features` anchor in TOC The link seems to have been broken with commit 7e55600a84e37d6b26656e44394438d975ae4909 ([pretty GH view][pretty-view]). [pretty-view]: https://github.com/vuejs/docs-next/commit/7e55600a84e37d6b26656e44394438d975ae4909#diff-c9868b6bf75c863c7384dcf155eb6497R35

view details

push time in a month

push eventErichDonGubler/docs-next

Erich Gubler

commit sha d6ac53e89560171416b18ca64a492d14eeab6957

fix: `introduction.md`: `notable-new-features` anchor in TOC The link seems to have been broken with commit 7e55600a84e37d6b26656e44394438d975ae4909 ([pretty GH view][pretty-view]). [pretty-view: ]https://github.com/vuejs/docs-next/commit/7e55600a84e37d6b26656e44394438d975ae4909#diff-c9868b6bf75c863c7384dcf155eb6497R35

view details

push time in a month

PR opened vuejs/docs-next

fix: `introduction.md`: `notable-new-features` anchor in TOC

Description of Problem

The "New Features" TOC link in the Introduction section of the migration guide is broken, because the current name and anchor of the section (New Features and new-features, respectively) does not match the current section name and anchor (Notable New Features and notable-new-features, respectively).

Proposed Solution

Fix the TOC item's title and link to match the new section name and anchor (Notable New Features and notable-new-features, respectively).

Additional Information

The link seems to have been broken with commit 7e55600a84e37d6b26656e44394438d975ae4909.

+1 -1

0 comment

1 changed file

pr created time in a month

push eventErichDonGubler/docs-next

Erich Gubler

commit sha abefa4ca568154be793a55df6f1d07bf7ff24120

fix: `introduction.md`: `notable-new-features` anchor in TOC The link seems to have been broken with commit 7e55600a84e37d6b26656e44394438d975ae4909.

view details

push time in a month

startedmrDIMAS/rg3d

started time in a month

startedalula/doukutsu-rs

started time in a month

PR opened NZXTCorp/ring

Reviewers
Static CRT linked with 0.16.15
+131929 -17

0 comment

117 changed files

pr created time in a month

create barnchNZXTCorp/ring

branch : static-crt-0.16.15

created branch time in a month

push eventNZXTCorp/ring

Nym Seddon

commit sha f2820869897aeeada86c5cd10ed062260f2e3489

Remove `Block` from `aead::{aes,chacha}::new_mask` Remove use of `Block` from `aead::{aes,chacha}::new_mask` API. Leave internal use of `Block` in `aead::aes::new_mask`. I agree to license my contributions to each file under the terms given at the top of each file I changed.

view details

Brian Smith

commit sha 57647365b077102b310d1ebff7b000cea8b30f75

AES: Remove dead AES-192 code.

view details

Nym Seddon

commit sha 0a5c2a78bedc851c9ec22555dae26c81da4032f3

Remove the use of `Block` from `aead::Tag`. I agree to license my contributions to each file under the terms given at the top of each file I changed.

view details

BlackHoleFox

commit sha 8ebd8e451df4a53724a4d26e2f3220de78dccdf4

Fix a PBKDF2 documentation comment typo

view details

push time in a month

create barnchNZXTCorp/ring

branch : main

created branch time in a month

push eventNZXTCorp/ring

David Benjamin

commit sha d59682c4274baaaed8b0818a1fa13bfd502cafc8

Fix runner tests with Go 1.13. Go 1.13 will add Ed25519 support to the standard library. Switch the order of our vendored Ed25519 bits so we do not get mixed up by this. When Go 1.13 is released, we can then unwind all this in favor of the standard library version. Update-Note: See b/135634259 Change-Id: Iddc0ea58db5b2181cecacfcdd3cc058159271787 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36504 Reviewed-by: Adam Langley <agl@google.com>

view details

Watson Ladd

commit sha 629f321ffd98992febd751526dd1c06eff5f921a

Add an API to record use of delegated credential Change-Id: Ie964dee5ff9f8c6d43208dd1d3947d9b427ea27d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36424 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Nick Harper

commit sha 7198a233689e250eb36d3d8e96b48b4cafb1be0a

Clarify language about default SSL_CTX session ticket key behavior. Change-Id: I8017a99ed99562b48a44d09da6a9338f1de9078f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36524 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha cfcb0060e8b8fba92d275fa4ac27d369890ea9bf

Emit empty signerInfos in PKCS#7 bundles. This is our bug that we've had since the beginning of PKCS#7 writing support in eeb9f491: the empty signerInfos SET wasn't emitted. Some parsers, including OpenSSL, don't like this but it appears to have taken five years for anyone to notice. This change does not make parsing strict so that we continue to parse old messages that we may have produced. (As ever, PKCS#* should not be used expect where absolutely required for interoperability.) Bug: b:135982177 Change-Id: Ia7241de69f105657bdfb5ff75e909deae71748a0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36564 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Steven Valdez

commit sha d6f9c359d219055a89c676cb8886421b145a08da

Factor out TLS cipher selection to ssl_choose_tls_cipher. This is factored out since ESNI will need to do its own cipher selection. Bug: 275 Change-Id: Id87fd91272fbcd9098b3f2a9caa78a2129b154b5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36544 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha 60cc4d4b4ee3ccaa530b1eeb29730efb28b5120b

Move fipstools/ to util/fipstools/cavp We have two “fipstools” directories, which is silly. Unify them into one by moving CAVP stuff into a subdirectory of util/fipstools. Change-Id: Ibeaa2205c58699f3d042445bfa6a6576a762da6f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36624 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Yun Liu

commit sha 3f98fde5addf628ede098491851c9122597fae5b

Add android_sdk checkout Bug: chromium:428426 Change-Id: I12c2969fe8b37a604b14300433f3e3f09aeb24e6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36584 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha 0086bd65c401e11605f9f92a95a4aa52d3bc9b04

Support key wrap with padding in CAVP. Change-Id: I27a282ee2b11083a1137990b00a9d599dd1f48df Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36625 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>

view details

Yun Liu

commit sha 365b7a0fcbf273b1fa704d151059e419abd6cfb8

Remove android_tools checkout Remove it when recipe change https://chromium-review.googlesource.com/c/chromium/tools/build/+/1685789 checked in and works as expected. Bug: chromium:428426 Change-Id: I649ba7f4bd003101c71d07faad2a0d1e957cb97e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36626 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha 09050cb498336655883157c6e6055db9e5542857

Add SipHash-2-4. The added code is a one-shot function. A handful of instructions could be saved by having a context object for repeated use of the same key, but perhaps it's not needed. Selected the 2-4 variant to implement because it seems to be overwhelmingly the most commonly used. Change-Id: I1e4f699f7dd5a2d35e12245fa116bafbd3439979 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36664 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Kris Kwiatkowski

commit sha 3c8ae0fd3ea5e390770ed67a9dd85b26a3854ab7

Implements SIKE/p434 * CECPQ2b will use SIKE/p434 instead of SIKE/p503 * KEM uses SHA256 instead of HMAC-256 * implements new starting curve: y^2=x^3 + 6x^2 + x * adds optimized implementation for aarch64 * adds optimized implementation for AMD64 which do not support MULX/ADOX/ADCX * syncs the SIKE test code with the NIST Round 2 specification. * removes references to field size from variables names, tests and defines. Change-Id: I5359c6c62ad342354c6d337f7ee525158586ec93 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36704 Reviewed-by: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha b7f0c1b4d3e7a630fab74e64a7a181defdff918e

Add initial draft of ACVP tool. ACVP will be the replacement for CAVP. CAVP is the FIPS 140 test-vector program. This commit contains some very rough support for ACVP. Currently it only supports hash functions and it's not hard to hit corner cases, but it's enough of a framework to work from. Change-Id: Ifcde18ac560710e252220282acd66d08e7507262 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36644 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha 0fc4979ddc54eaa28b62af3cbf72ac870444bc52

Fix shim error message endings. A few fprintfs were missing newlines at the end of the message. A few more were missing periods. This change makes them all consistent. Change-Id: Ib275a9543414f34a7bee5bb9ec3cba37c9ec3cf8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36724 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha a86c69888b9a416f5249aacb4690a765be064969

Add post-quantum experiment signal extension. When testing HRSS-SXY and SIKE, we also want a control group. However, how are clients to indicate that they're part of the 1/3 of the experiment population that's not advertising CECPQ? And how are servers to indicate that they would have negotiated CECPQ2 / 2b if only the client had asked? This change adds a temporary signaling extension to solve these issues. Change-Id: Ic087a09149ef10141568b734396981ae97950a9b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36725 Reviewed-by: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha 1a3178cf028b1fd58b7bd2c322678d39df91c218

Rename SIKE's params.c. We already have crypto/dh/params.c and some of our downstream consumers cannot take two source files with the same name in the same build target. Change-Id: I324ace094c2215b443e98fc9ae69876ea1929efa Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36744 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha 07432f325d6a388fe6d4881e84b076610c961f05

Prefix all the SIKE symbols. I should have noticed this previously, but the SIKE code was exporting symbols called generic things like “params”. They're not dynamically exported, but BoringSSL is often statically linked so better to ensure that these things are prefixed to avoid the risk of collisions. Change-Id: I3a942dbc8f4eab703d5f1d6898f67513fd7b578c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36745 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha 66e106026aa6efb7e7266d5fd36ef27f30757d43

Align TLS 1.3 cipher suite names with OpenSSL. There are two naming conventions for TLS cipher suites, the standard IETF names (SSL_CIPHER_standard_name) and the ad-hoc OpenSSL names (SSL_CIPHER_get_name). When we added TLS 1.3, we had to come up with OpenSSL-style names for the cipher suites. OpenSSL-style names use hyphens rather than underscores (and omit underscores in odd places), so the natural name for TLS_AES_128_GCM_SHA256 would have been "AES128-GCM-SHA256". However, that name is already taken by TLS_RSA_WITH_AES_128_GCM_SHA256 because OpenSSL's naming convention treats the legacy RSA key exchange as default. Instead, we used an "AEAD-" prefix to indicate the ciphers only specified the AEAD. Since then, OpenSSL has implemented TLS 1.3. Instead, they simply made the OpenSSL-style name match the standard name starting TLS 1.3, underscores and all. (This is why openssl s_client will return very different-looking cipher names in TLS 1.2 and TLS 1.3.) Align with OpenSSL and do the same. Update-Note: SSL_CIPHER_get_name will return different values for TLS 1.3 ciphers than before. Note that we did not allow TLS 1.3 ciphers to be configured at all, so no cipher suite configurations will need to change, but code logging or asserting on the result of a TLS connection may observe differences. It is also recommended that consumers replace uses of SSL_CIPHER_get_name with SSL_CIPHER_standard_name which gives a much more consistent naming convention. (BoringSSL supports both standard and OpenSSL names in the cipher suite configuration, so there's no need to use OpenSSL names at all.) Change-Id: I40b1de0689dd7b32af88602acc063934f2877999 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36764 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha b9e2b8adcd05e46c4dbf93435661e077f9b583cb

Name cipher suite tests in runner by IETF names. The names of those tests don't actually matter to the shim because we don't pass them in anywhere. Note hasComponent() is also used by the signature algorithm tests, so that also needs to use underscores as a result. Change-Id: I393df4c6ffebcc66a55f256df5a641ad87e66441 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36765 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha 9f5c419b9fbb0d10943f14829470130701af2f4b

Move the PQ-experiment signal to SSL_CTX. In the case where I need it, it's easier for it to be on the context rather than on each connection. Change-Id: I5da2929ae6825d6b3151ccabb813cb8ad16416a1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36746 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha 4dfd5af70191b068aebe567b8e29ce108cee85ce

Only bypass the signature verification itself in fuzzer mode. Keep the setup_ctx logic, which, among other things, checks if the signature algorithm is valid. This cuts down on some unnecessary fuzzer-mode suppressions. Change-Id: I644f75630791c9741a1b372e5f83ae7ff9f01c2f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36766 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in a month

created tagNZXTCorp/ring

tag0.16.15

Safe, fast, small crypto using Rust

created time in a month

startedShnatsel/rust-audit

started time in a month

startedpandaman64/serde-query

started time in a month

startedyamafaktory/craftql

started time in a month

startedEikeSchulze/u16_tic_tac_toe

started time in a month

starteddropbox/pb-jelly

started time in a month

startedUriopass/inline_tweak

started time in a month

startedLukasKalbertodt/bunt

started time in a month

startedKoffeinFlummi/rustbucket

started time in a month

issue commentwebinstall/packages

add capability to convert key to putty (ppk)

Mm, but maybe not for Windows: https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/puttygen-batch.html

ryanburnette

comment created time in a month

issue commentwebinstall/packages

add capability to convert key to putty (ppk)

Hmm, looks like there might be a command line interface too: https://www.ssh.com/ssh/putty/linux/puttygen

ryanburnette

comment created time in a month

issue commentwebinstall/packages

add capability to convert key to putty (ppk)

Doesn't PuTTYgen already do conversion between ppk and pem in both directions? That's a GUI flow, but it IS part of the PuTTY ecosystem and probably local with whatever machines are generating ppk files.

ryanburnette

comment created time in a month

startedmagiclen/lazy-static-include

started time in a month

pull request commentbriansmith/ring

Move from `spin` to `conquer-once`

The CI failures here don't seem related, esp. since they're occurring in other PRs right now (for example, this one).

ErichDonGubler

comment created time in a month

startedtenderlove/analog-terminal-bell

started time in a month

issue commentgetsentry/sentry-rust

Client doesn't log errors

I unfortunately am not familiar with usage of sentry as a crate, though I'm now responsible for a codebase that uses it with @NZXTCorp. I would defer information gathering to @GeorgeHahn and @WhyNotHugo, since I haven't reproduced the issue myself yet -- I'm just assessing risk with issues for my team right now. :)

WhyNotHugo

comment created time in 2 months

issue commentbodil/sized-chunks

Multiple soundness issues in Chunk and InlineArray

@Qwaz: Just wanted to confirm: should the advisory note that this affects the 0.6.x releases that are already live? Right now it only states that 0.5.3, but in this issue your OP states that this reproduces with 0.6.2 (the latest release at time of writing).

Qwaz

comment created time in 2 months

PR opened briansmith/ring

Move from `spin` to `conquer-once`

This resolves RUSTSEC-2019-0031.


The advisory page suggests several alternatives to the now-deprecated spin crate. The reason I picked conquer-once was because it seemed to have the most similar (and limited) API to how spin was being used -- it seemed a good small dependency to trade for.

+3 -3

0 comment

2 changed files

pr created time in 2 months

create barnchErichDonGubler/ring

branch : move-from-spin-to-conquer_once

created branch time in 2 months

issue commentgetsentry/sentry-rust

Client doesn't log errors

This hasn't been resolved with 0.20.0, has it?

WhyNotHugo

comment created time in 2 months

startedopenjdk/jdk

started time in 2 months

issue commentjmesmon/rust-systemd

Add GCC Linking exception (spdx: GCC-exception-2.0) to clarify linking the rust systemd library into non (L)GPL programs

I support this, but I don't have any illusions that my contributions were sizable here. :)

jmesmon

comment created time in 2 months

issue commentrust-lang/rust

Tracking issue for methods converting `bool` to `Option<T>`

@sanbox-irl: My first thought about bool::some looking strange at the call site is that that might be alleviated by infusing some of the other semantics suggested into it, i.e., and_some, and_then_some:

rust_is_awesome.and_then_some(|| "woot")
failed.and_some(success_value)
varkor

comment created time in 2 months

push eventErichDonGubler/clippy-check-windows-lf-failures

Erich Gubler

commit sha 46cc879240c0b117e3b54f0a7ca7a19509eb4a19

Initial commit: MRE for a clippy-check issue See https://github.com/actions-rs/clippy-check/pull/102

view details

push time in 2 months

push eventErichDonGubler/clippy-check-windows-lf-failures

Erich Gubler

commit sha 2c6118170bc0bd8c79f94b07fe977a07c94537b8

Initial commit: MRE for a clippy-check issue See https://github.com/actions-rs/clippy-check/pull/102

view details

push time in 2 months

create barnchErichDonGubler/clippy-check-windows-lf-failures

branch : master

created branch time in 2 months

more