profile
viewpoint

newpavlov/fsm-bench 12

Benchmark of Finite State Machine approaches

newpavlov/parstream 12

Compute function over iterator in a streaming fashion using thread pool and preserving order of elements

brson/rust-sha2 6

SHA-2 in pure Rust

newpavlov/durations-rs 3

Duration constants

newpavlov/lag-test 1

Simple application for testing input lag using Vulkano + winit

icevision/solutions 0

Solutions submitted by participants

icevision/velodyne-conv 0

Velodyne PCAP convertation utility

newpavlov/advisory-db 0

Security advisory database for Rust crates published through crates.io

newpavlov/ansible-vault-rs 0

Decrypt ansible vault 1.1 files in Rust

issue commentRustCrypto/traits

block-cipher: Block alignment

I am not sure if such change will be practical, at least with the current state of the Rust language. Don't forget that we build other APIs on top of BlockCipher. Such change would either require bubbling alignment restrictions to higher-level APIs and thus removing the convenience of using &mut [u8], or we would have to keep two parallel sets of methods with and without those restrictions.

On modern x86 unaligned loads of aligned pointers have the same performance, but unfortunately it's indeed not true for ARM...

nickray

comment created time in 9 hours

push eventRustCrypto/utils

Артём Павлов

commit sha 958403d51594785cfcad4d88aff5ba3ef00b93dd

fix cargo.toml

view details

push time in a day

pull request commentRustCrypto/traits

build(deps): bump subtle from 2.2.2 to 2.2.3

Hm, shouldn't we also test minimum dependency versions?

dependabot-preview[bot]

comment created time in a day

PR opened RustCrypto/utils

hex-literal v0.3

This version will work only in Rust 1.45 and later.

+79 -328

0 comment

6 changed files

pr created time in a day

create barnchRustCrypto/utils

branch : hex-literal3

created branch time in a day

created tagRustCrypto/utils

taghex-literal-impl-v0.2.2

Utility crates used in the rust-crypto

created time in a day

push eventRustCrypto/utils

Artyom Pavlov

commit sha 2aae8a40556e166e9ca06aebc944091dda24b769

bump hex-literal-impl to v0.2.2 (#52)

view details

push time in a day

PR merged RustCrypto/utils

Bump hex-literal-impl to v0.2.2
+1 -1

0 comment

1 changed file

newpavlov

pr closed time in a day

PR opened RustCrypto/utils

Bump hex-literal-impl to v0.2.2
+1 -1

0 comment

1 changed file

pr created time in a day

create barnchRustCrypto/utils

branch : hex_bump

created branch time in a day

push eventRustCrypto/utils

Aaron Hill

commit sha bd10ffa38416864868fbe636d5a1bb4f77ae8dec

Handle `Group`s with `Delimiter::None` (#50) Currently, rustc does not pass the exact original `TokenStream` to proc-macros in several cases. This has many undesirable effects, such as losing correct location information in error message. See https://github.com/rust-lang/rust/issues/43081 for more details In the future, rustc will begin passing the correct `TokenStream` to proc-macros. As a result, some tokens may be wrapped in a `TokenTree::Group` with `Delimiter::None` (when the tokens originally came from a `macro_rules!`) macro expansion. I've determined that this change will cause your crate to stop working on some inputs. This PR updates `hex-literal-impl` to be compatible with both the old and new `TokenStream` contents. If you have any questions, feel free to ask me. See https://github.com/rust-lang/rust/issues/72622 for more details

view details

push time in a day

PR merged RustCrypto/utils

Handle `Group`s with `Delimiter::None`

Currently, rustc does not pass the exact original TokenStream to proc-macros in several cases. This has many undesirable effects, such as losing correct location information in error message. See https://github.com/rust-lang/rust/issues/43081 for more details

In the future, rustc will begin passing the correct TokenStream to proc-macros. As a result, some tokens may be wrapped in a TokenTree::Group with Delimiter::None (when the tokens originally came from a macro_rules!) macro expansion.

I've determined that this change will cause your crate to stop working on some inputs. This PR updates hex-literal-impl to be compatible with both the old and new TokenStream contents.

If you have any questions, feel free to ask me. See https://github.com/rust-lang/rust/issues/72622 for more details

+23 -2

0 comment

1 changed file

Aaron1011

pr closed time in a day

push eventnewpavlov/fsm-bench

Артём Павлов [Artyom Pavlov]

commit sha 081f27c0789bdc2bf129ada474145000fe3cc5b0

smallfix

view details

push time in 2 days

push eventnewpavlov/fsm-bench

Артём Павлов [Artyom Pavlov]

commit sha b0f2e40ad0e1ba5bf1896832401700d8d7eaa238

update

view details

push time in 2 days

push eventnewpavlov/fsm-bench

Reinier Maas

commit sha 2801cc35a39ab50a4b38a737d59b78e023df80bb

Fix typo in readme aech - > each

view details

Artyom Pavlov

commit sha 0fd9249c30eaf760978d61faea5e36dd5b695414

Merge pull request #1 from ReinierMaas/patch-1 Fix typo in readme

view details

push time in 2 days

PR merged newpavlov/fsm-bench

Fix typo in readme

aech - > each

+1 -1

1 comment

1 changed file

ReinierMaas

pr closed time in 2 days

pull request commentnewpavlov/fsm-bench

Fix typo in readme

Thank you!

ReinierMaas

comment created time in 2 days

push eventnewpavlov/fsm-bench

Артём Павлов [Artyom Pavlov]

commit sha 81d1047e33beb0ff9bee4a4b63328e62058982fe

update

view details

push time in 2 days

push eventnewpavlov/fsm-bench

Артём Павлов [Artyom Pavlov]

commit sha 51963073f6c14867fa17770fb1e625bd4236b4f4

update

view details

push time in 2 days

push eventnewpavlov/fsm-bench

Артём Павлов [Artyom Pavlov]

commit sha dd067cb6a1e4df61a945bf31020d8c30f8aa59e4

update

view details

push time in 2 days

push eventnewpavlov/fsm-bench

Артём Павлов [Artyom Pavlov]

commit sha 9de0a8b0d9c78666f228dc1efff8bea76a8bb208

add comma

view details

push time in 2 days

push eventnewpavlov/fsm-bench

Артём Павлов [Artyom Pavlov]

commit sha f39c9acc78b5b5150356dbb9b53dc5553415dbc6

update

view details

push time in 2 days

push eventnewpavlov/fsm-bench

Артём Павлов [Artyom Pavlov]

commit sha 5ec13f7a705fe49a3c4c0510b8d21ceadadde26a

small improvement

view details

push time in 2 days

push eventnewpavlov/fsm-bench

Артём Павлов [Artyom Pavlov]

commit sha 03a2be04df9adbf184c26ea0c705ce56b125df27

update code comment

view details

push time in 2 days

create barnchnewpavlov/fsm-bench

branch : master

created branch time in 2 days

created repositorynewpavlov/fsm-bench

Benchmark of Finite State Machine approaches

created time in 2 days

issue commentRustCrypto/utils

Use ref in hex macro

I am not sure it will be possible to do in the near future, since const fn will receive &str without any indication of length, so we will not be able to compute length of the output array. Jne thing which I am looking forward to is removal of the proc-macro-hack dependency, although it will result in bumping MSRV to the future stable.

Slals

comment created time in 4 days

issue closedRustCrypto/utils

Use ref in hex macro

Hello,

Is there a work arround to use ref instead of string literal in hex!?

let key = String::from("ff00ff00ff00ff00ff00");
hex!(key.as_str()); // expected one string literal

Does this macro should include format such as println!("{}", key)? If so I can make a PR but I'm not so sure.

Thanks

closed time in 4 days

Slals

issue commentRustCrypto/utils

Use ref in hex macro

Unfortunately it's not possible. hex! macro has to expand at compile-time. For runtime transformation check out the hex crate.

Slals

comment created time in 4 days

push eventnewpavlov/Presentations

Artyom Pavlov

commit sha d09bda401fc6a4813138099b365df6085d0a2591

code update

view details

push time in 4 days

push eventnewpavlov/Presentations

Artyom Pavlov

commit sha 030db7ebbec1a4482137bf7c50f5b92ea50dc7a6

update

view details

push time in 4 days

push eventnewpavlov/Presentations

Artyom Pavlov

commit sha ad42f041680f4f1e4c9564edce3df1b85385c29f

add null pointer

view details

push time in 4 days

push eventnewpavlov/Presentations

Artyom Pavlov

commit sha bc6c6dfb8454f73bd7b24280ccceb391e78a0a08

add links

view details

push time in 4 days

push eventnewpavlov/Presentations

Artyom Pavlov

commit sha b76579aa1edbb7afbae24199bc788f835c9b7751

update first slide

view details

push time in 4 days

push eventnewpavlov/Presentations

Artyom Pavlov

commit sha 005b808d14ac856b0a257047c9a1b9752049022c

update errors

view details

push time in 4 days

push eventnewpavlov/Presentations

Artyom Pavlov

commit sha fcf4ed1d15740b836f686e75097567d74601b0fa

Set theme jekyll-theme-slate

view details

push time in 4 days

fork newpavlov/Presentations

Slides and presentations

fork in 4 days

issue commentRustCrypto/block-ciphers

BlockMode::decrypt truncates output at first zero byte?

I guess you are using ZeroPadding, correct? In this case this behavior is intentional. If we are to trust wiki, then such behavior is described in ISO/IEC 10118-1 and ISO/IEC 9797-1. My guess is that hazmat leaves the trailing zero to keep compatibility with C null-terminated strings (probably because it uses OpenSSL as a backend).

nickray

comment created time in 4 days

issue commentRustCrypto/block-ciphers

AES implementation should be chosen at runtime rather than compile time

CPUID instruction itself certainly is not cheap (measured throughput can take up to 1500 cycles), but is_x86_feature_detected caches result into an atomic variable, so it's relatively cheap, but I am hesitant to put it into a tight loop. Also it probably will not play well with the optimized AES-CTR code, which was specifically written to keep all key data in XMM registers when possible (runtime detection will mean that CPU may have to unload key data into general purpose registers). Another (minor) problem is that is_x86_feature_detected is not available on no_std, we could implement our own detection like it was done in getrandom. It's certainly not ideal, but should work fine.

I guess we should benchmark runtime detection on the level of the aes crate and if the performance impact is minor enough (say less than 1%) got with such solution for user convenience sake.

upsuper

comment created time in 4 days

pull request commentrust-random/getrandom

cpu: Have "cpu" feature take precedence over "custom"

Just rename the feature to "rdrand"

Sounds good.

josephlr

comment created time in 5 days

pull request commentrust-random/getrandom

Move wasm32 Custom RNG impls back to main crate

They do not show up in the Cargo.lock of any crate that depends on getrandom

Good to know! I was afraid that it would be necessary to bring all those WASM dependencies in the vendoring scenario.

I don't think we will be able to use the custom crate under the hood until the target-specific feature issue gets resolved

Hm, I am not sure how absence of target-specific features blocks moving WASM implementation into a separate crate. But I realized that my proposal unfortunately has a problem: getrandom-js would not be able to enable the custom feature and be an optional dependency of getrandom at the same time, since it would result in a cyclic dependency.

I still don't like bringing WASM code back into getrandom and using the js feature, especially if it will take precedents over the custom feature (I would not be surprised if js will get unconditionally enabled for any sufficiently large dependency tree, thus making it impractical to define custom sources for non-JS WASM applications outside of WASI), but I guess I can live with it.

josephlr

comment created time in 5 days

pull request commentrust-random/getrandom

Move wasm32 Custom RNG impls back to main crate

I really dislike the fact that adding js feature results in 53 dependencies being added to Cargo.lock (47 if we exclude wasm-bindgen-test), which is not a small number. I understand the desire to assume JS environment for convenience sake, but I don't think it's a good long-term solution. I guess as a compromise we could add the js feature, which would use the custom crate under the hood and would emit a deprecation notice with a link to docs explaining how to use custom crates. It will not save us from the pollution problem, but would guide users to migration without breaking their builds. Removal of this feature can be postponed until v0.3/v1.0 release.

then users would use that function (w/ register_custom_getrandom!()) in their root crate

If the registration macro will originate in getrandom, then users would have to add both getrandom and the custom crate to their Cargo.toml (so alloc is different in this regard), which is suboptimal. Since the registration macro is quite simple, I don't see why it has to be included into getrandom.

josephlr

comment created time in 5 days

issue closedRustCrypto/hashes

docs.rs: view source cuts off left side

When viewing source on docs.rs, the entire left side of the code listing is not visible. For example, viewing https://docs.rs/sha3/0.8.2/src/sha3/lib.rs.html#1-96:

image

These links are generated by clicking on [src] anywhere in the documentation.

closed time in 5 days

xobs

pull request commentrust-random/getrandom

Move wasm32 Custom RNG impls back to main crate

@Pauan

that approach won't work for all crates

Can you elaborate? As for zero-cost, firstly it's cost is really negligible, especially when compared to the cost of calling into JS world. And secondly, if I am not mistaken LTO should be able to optimize such code.

That seems strictly worse than using compile_error!

Yes, it's less convenient and clear, but it could be worked around. (see below)

enabling a feature is an explicit opt-in change which people only do when they need to enable that feature.

The problem is that feature can be enabled anywhere in your dependency tree and it could be quite hard to find the source of the problem, while finding the crate which has added a custom crate is much easier. Also there is a problem of feature unification between dev and non-dev builds, granted it only affects crates in the same workspace (if I remember correctly), but still it could be quite annoying.

Another problem is potential breaking changes in getrandom. You could have both 0.2 and 0.3 crates in your dependency tree and you would have to enable the feature for both of them, while with the custom crate approach it will work with the both versions simultaneously (assuming the extern function signature is not changed).

@josephlr Don't forget that users will really rarely depend on getrandom directly. The example with Cargo.toml provided by you is a clear misuse of the crate and it should be indicated in docs as such. I agree that the use and the linking errors issues are certainly drawbacks of the approach, but I think they can be worked around.

First, about the use issue. I like your registering proposal, but I think it would work better with a custom crate. Code in an application crate could call getrandom_js::register!();, which would define the extern function and it could emit a compilation error on non-wasm32-unknown-unknown targets, thus promoting correct cfg-ing of the registration calls. It's a bit closer to how global allocators get registered, so it may be a bit more familiar to users.

Second, about the error issue. We could add special features to getrandom (e.g. custom_js or custom_wasmbindgen/custom_stdweb, as well as custom_cpu), specific to some common custom crates. If more than one of the custom features will get enabled, we would emit a compile_error!. This way the compilation error will happen before the linking error.

josephlr

comment created time in 5 days

pull request commentrust-random/getrandom

Combine wasm32 Custom RNG crates

what if one crate uses getrandom-stdweb and another crate uses getrandom-wasm-bindgen?

It will result in a linking error with the following description rust-lld: error: duplicate symbol: __getrandom_custom. Either way, using custom crate as a non-dev dependency in a library crate is a 100% bug (our documentation could use improvement here), which I think is harder to make compared to features screw-up.

Even if my application installs getrandom-wasm-bindgen, that won't affect foo, so that doesn't work.

No, it will be affected. I think you misunderstand how custom crates work. With an enabled custom feature, getrandom uses an extern function on unsupported targets. Custom crates enable this feature and define the function via register_custom_getrandom macro. So when application crate adds a custom crate into its dependency tree, it will influence all users of getrandom simultaneously. So again, it's a library-space emulation of the alloc functionality.

josephlr

comment created time in 6 days

pull request commentrust-random/getrandom

Combine wasm32 Custom RNG crates

It is flexible, and Cargo features are transitive, which is generally what you want.

I don't think so. We can't define mutually exclusive features, so if one of your dependencies wrongly enables such feature (be it for convenience sake or as a mistake), it will infect all downstream crates. In other words, the more crates in your dependency tree the more likely situation that both wasm-bingen and stdweb features will get enabled, thus removing an ability for you to choose between them. Also it endorses proxying features, which I believe results in unnecessary churn in Cargo.toml.

Having a separate crate doesn't work as good, because it doesn't work with transitive dependencies.

Can you elaborate? The idea behind the custom crates, is that they get included only in application crates or as a dev dependency for benches and tests. It's essentially similar to how alloc works, but without language support, which leads to the minor use churn.

josephlr

comment created time in 6 days

pull request commentRustCrypto/block-ciphers

aesni: use MaybeUninit::zeroed() to init XMM registers

Why not use shorter mem::zeroed() instead? AFAIK it's not getting deprecated as mem::uninitialied()

tarcieri

comment created time in 6 days

Pull request review commentRustCrypto/block-ciphers

Fix or whitelist clippy nits

 macro_rules! expand_round {  #[inline(always)] pub(super) fn expand(key: &[u8; 16]) -> ([__m128i; 11], [__m128i; 11]) {+    // TODO: eliminate usage of `MaybeUninit` and/or verify soundness

We probably can replace it with mem::zeroed(), since compiler can properly optimize it (assembly is equivalent to the code using MaybeUninit).

tarcieri

comment created time in 6 days

pull request commentRustCrypto/block-ciphers

Bump all versions to `*-pre`

When you'll start publishing please omit kuznyechik and magma. To be compatible with common implementations BE order has to be used, instead of the wrongly used LE, so I would like to fix it before the breaking update.

tarcieri

comment created time in 6 days

delete branch RustCrypto/hashes

delete branch : newpavlov-patch-1

delete time in 7 days

push eventRustCrypto/hashes

Artyom Pavlov

commit sha 79672446dd4b4649c45e8fdc6f4babce2f6d0526

describe how to disable the `std` feature (#113)

view details

push time in 7 days

PR merged RustCrypto/hashes

Describe how to disable the `std` feature

Closes #105

+8 -0

0 comment

1 changed file

newpavlov

pr closed time in 7 days

issue closedRustCrypto/hashes

README: describe how to use no_std

Currently, the README states that it's possible to use these crates with no_std. However, it does not say how to do so.

A simple one-line example for Cargo.toml would be nice.

closed time in 7 days

xobs

pull request commentRustCrypto/traits

WIP Add "aead::encrypt_fixed_length" and "aead::decrypt_fixed_length"

I think it also would be nice to think about such functionality in the context of future migration to const generics. IIUC at the early stages they will be less powerful than typenum, so I am not sure if it will be possible to translate API in this PR.

garbageslam

comment created time in 7 days

pull request commentrust-random/getrandom

Combine wasm32 Custom RNG crates

However, for wasm32, even our code to check that the APIs are there requires knowing the type of environment we are in.

I am not sure if I fully understood you here, but I think you forgot about the wasm32-wasi target. :) Ideally we would have something like wasm32-web, but it does not look like it will happen in the near future.

The only (minor) downside to the second approach is that the user also has to write use getrandom_js as _; in their crate.

Oh, you are right. I didn't know that cargo may not link crate depending on source code even though it compiles it. I wonder if we can work around it somehow, e.g. via build scripts in the custom crate...

I think that whatever we do here will not affect what we do for libstd, as we will only use getrandom on non-wasm32-unknown-unknown platforms.

It was mostly about the "unconditional support" variant. One minor drawback of moving from the custom crate is that it would require whitelisting (unused) WASM crates, which is not ideal (i.e. as you said it would pollute std's lock file).

josephlr

comment created time in 7 days

pull request commentrust-random/getrandom

Combine wasm32 Custom RNG crates

I don't think there is a big difference between adding getrandom = { version="0.2", features = ["js"] } and getrandom-js = "0.2" into a project's Cargo.toml. The second option is shorter, albeit probably less familiar. Also I think it's easier to enable js feature by mistake, than add non-dev getrandom-js dependency.

As for the cpu feature, we can infer the necessary capabilities from target triplets, so situation is different from strict PoV (also I am not 100% sure if CPU randomness should be implemented as a feature-gated functionality and not as a custom crate).

josephlr

comment created time in 7 days

pull request commentrust-random/getrandom

Combine wasm32 Custom RNG crates

I am not closely familiar with Rust WASM ecosystem, so I can't comment on universality of such solution (e.g. should we care about users of older cargo web? or what about alternative tools?), so I hope others will comment on that.

Now that we can detect most of the ambiguity at compile time, does it even make sense to have this as an external RNG?

Personally I believe we should keep it as an external RNG. Supporting wasm32-unknown-unknown in getrandom is wrong in a certain sense, since the target triplet does not tell anything about environment. Plus don't forget about the potential integration of getrandom into std (I hope to revive the PR after v0.2 release).

If we keep this as an external RNG, do we like the getrandom-js name?

Sounds good to me.

josephlr

comment created time in 7 days

issue openedTinkoffCreditSystems/invest-openapi

Добавить возможность получения более чем 20 позиций в стакане

В идеале, конечно хотелось бы видеть вообще все активные заявки. Если есть опасения о чрезмерном увеличении объёма трафика, то было бы неплохо добавить расширение использующее бинарные сообщения в котором цена и количество заявок передавалось бы в виде сырых int-ов. Если этого будет недостаточно, то возможно использование сообщений, которые бы передавали diff-ы относительно снапшота стакана.

created time in 7 days

PR opened RustCrypto/hashes

Describe how to disable the `std` feature

Closes #105

+8 -0

0 comment

1 changed file

pr created time in 7 days

create barnchRustCrypto/hashes

branch : newpavlov-patch-1

created branch time in 7 days

issue commentRustCrypto/hashes

docs.rs: view source cuts off left side

The problem is in z-index: 1; property. Surprisingly, it looks like docs.rs uses different CSS files for different crates, for example it's rustdoc-20190417-1.36.0-nightly-3c3d3c177.css and rustdoc-20200522-1.45.0-nightly-215f2d329.css for sha3 v0.8.2 and sha2 v0.8.2 pages respectively. So if I am not mistaken this issue will be "fixed" on a next crate upload, thus I think we can close it.

Additionally you can create an issue in the docs.rs repository, so they could regenerate pages with a fixed CSS file.

xobs

comment created time in 7 days

delete branch newpavlov/rust-isp-2019

delete branch : dependabot/bundler/rubyzip-2.2.0

delete time in 9 days

push eventnewpavlov/rust-isp-2019

dependabot[bot]

commit sha 4a894742f75dbb74644929c1cf481b400e4325d9

Bump rubyzip from 1.2.2 to 2.2.0 (#3)

view details

push time in 9 days

PR merged newpavlov/rust-isp-2019

Bump rubyzip from 1.2.2 to 2.2.0 dependencies

Bumps rubyzip from 1.2.2 to 2.2.0. <details> <summary>Release notes</summary>

Sourced from rubyzip's releases.

v2.2.0

  • Add support for decompression plugin gems #427

v2.1.0

  • Fix (at least partially) the restore_times and restore_permissions options to Zip::File.new #413
    • Previously, neither option did anything, regardless of what it was set to. We have therefore defaulted them to false to preserve the current behavior, for the time being. If you have explicitly set either to true, it will now have an effect.
    • Fix handling of UniversalTime (mtime, atime, ctime) fields. #421
    • Previously, Zip::File did not pass the options to Zip::Entry in some cases. #423
    • Note that restore_times in this release does nothing on Windows and only restores mtime, not atime or ctime.
  • Allow Zip::File.open to take an options hash like Zip::File.new #418
  • Always print warnings with warn, instead of a mix of puts and warn #416
  • Create temporary files in the system temporary directory instead of the directory of the zip file #411
  • Drop unused tmpdir requirement #411

Tooling

  • Move CI to xenial and include jruby on JDK11 #419

v2.0.0

Security

  • Default the validate_entry_sizes option to true, so that callers can trust an entry's reported size when using extract #403
    • This option defaulted to false in 1.3.0 for backward compatibility, but it now defaults to true. If you are using an older version of ruby and can't yet upgrade to 2.x, you can still use 1.3.0 and set the option to true.

Tooling / Documentation

  • Remove test files from the gem to avoid problems with antivirus detections on the test files #405 / #384
  • Drop support for unsupported ruby versions #406

v1.3.0

Security

  • Add validate_entry_sizes option so that callers can trust an entry's reported size when using extract #403
    • This option defaults to false for backward compatibility in this release, but you are strongly encouraged to set it to true. It will default to true in rubyzip 2.0.

New Feature

  • Add add_stored method to simplify adding entries without compression #366

Tooling / Documentation

  • Add more gem metadata links #402

v1.2.4

  • Do not rewrite zip files opened with open_buffer that have not changed #360

Tooling / Documentation

  • Update example_recursive.rb in README #397
  • Hold CI at trusty for now, automatically pick the latest ruby patch version, use rbx-4 and hold jruby at 9.1 #399 </tr></table> ... (truncated) </details> <details> <summary>Changelog</summary>

Sourced from rubyzip's changelog.

2.2.0 (2020-02-01)

  • Add support for decompression plugin gems #427

2.1.0 (2020-01-25)

  • Fix (at least partially) the restore_times and restore_permissions options to Zip::File.new #413
    • Previously, neither option did anything, regardless of what it was set to. We have therefore defaulted them to false to preserve the current behavior, for the time being. If you have explicitly set either to true, it will now have an effect.
    • Fix handling of UniversalTime (mtime, atime, ctime) fields. #421
    • Previously, Zip::File did not pass the options to Zip::Entry in some cases. #423
    • Note that restore_times in this release does nothing on Windows and only restores mtime, not atime or ctime.
  • Allow Zip::File.open to take an options hash like Zip::File.new #418
  • Always print warnings with warn, instead of a mix of puts and warn #416
  • Create temporary files in the system temporary directory instead of the directory of the zip file #411
  • Drop unused tmpdir requirement #411

Tooling

  • Move CI to xenial and include jruby on JDK11 #419

2.0.0 (2019-09-25)

Security

  • Default the validate_entry_sizes option to true, so that callers can trust an entry's reported size when using extract #403
    • This option defaulted to false in 1.3.0 for backward compatibility, but it now defaults to true. If you are using an older version of ruby and can't yet upgrade to 2.x, you can still use 1.3.0 and set the option to true.

Tooling / Documentation

  • Remove test files from the gem to avoid problems with antivirus detections on the test files #405 / #384
  • Drop support for unsupported ruby versions #406

1.3.0 (2019-09-25)

Security

  • Add validate_entry_sizes option so that callers can trust an entry's reported size when using extract #403
    • This option defaults to false for backward compatibility in this release, but you are strongly encouraged to set it to true. It will default to true in rubyzip 2.0.

New Feature

  • Add add_stored method to simplify adding entries without compression #366

Tooling / Documentation

  • Add more gem metadata links #402

1.2.4 (2019-09-06)

  • Do not rewrite zip files opened with open_buffer that have not changed #360 </tr></table> ... (truncated) </details> <details> <summary>Commits</summary>
  • ecd641e Merge pull request #429 from rubyzip/v2-2-0
  • f42827e Bump version to 2.2.0
  • 040962a Remove unused error argument
  • 666fb8c Merge pull request #427 from jspanjers/refactor-decompressor
  • 0b9433c Add test for unsupported decompression, e.g bzip2
  • a5d068d Support Decompressor plugins
  • 2b72683 Define compression methods
  • 456bd4d Mimic IO#read return values in Decompressor#read
  • c66277d Rename Decompressor#sysread to #read
  • 00b525d Fix returned outbuf for Inflater#sysread
  • Additional commits viewable in compare view </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+1 -1

0 comment

1 changed file

dependabot[bot]

pr closed time in 9 days

issue commentRustCrypto/traits

Contingency plan for new crate releases

Greetings everyone!

I am sorry for this uncomfortable situation. Due to personal reasons (not connected to the COVID situation), I've generally taken a break from programming and become significantly less active online. As mentioned in the OP, I've given @tarcieri an owner access to this organization before the break (so bus factor is at least 2 now!). Most crates handled by RustCrypto can be updated by members of respective teams, but unfortunately I forgot to do it for the trait crates. I will fix this oversight right away.

I plan to be more active in the following months and thus reduce backlog of the accumulated issues. Also my work will be partially supported by a company which is interested in using pure-Rust crypto in their products, so I will have some financial incentives to continue work on the RustCrypto crates. :)

tarcieri

comment created time in 10 days

startedSmithay/smithay

started time in 22 days

issue commentSkoltechRobotics/oscar-cli

Image grayscale

Add -d flag, which will apply bi-linear demosaicing. You can see documentation for other options using -h flag.

BTW you can download pre-compiled version from the releases page.

DmitryProkin

comment created time in a month

issue commentrust-random/rand

Stop forwarding getrandom's wasm features

if I need a version of getrandom which is incomptible with the version the dep of a dep of me is using.

But there are no such versions right now and in the future version there will be no features to forward! During transition period when apps will have both getrandom v0.1 and getrandom v0.2 in their dependency tree, they would have to use both lines which I provided. It's certainly not ideal, but I think it should manageable.

rand v0.7 users may continue to use wasm-bindgen feature as usual, although I would recommend to use the approach in my previous message instead of feature forwarding.

Splitting crates seems like a very rough approach to an issue which is basically what features are made to solve (I guess).

The issue is not WASM specific, similar problems arise for other targets, such as embedded or UEFI. Custom crates is essentially our way to emulate alloc approach without language-level support. We couldn't find a better solution after lengthy pondering about this issue. With this approach users will be able to write their own custom crates without merging their code (which could be highly specialized) into getrandom, thus they will be able to use the rand ecosystem and crates which depend on it in their projects.

dhardy

comment created time in 2 months

pull request commentrust-random/getrandom

Fixing Webpack require warning when using wasm-bindgen

Looks good to me, but I am not familiar with webpack and Node, so I would prefer for someone else to take a look at it. CI failures are not caused by this PR, but I think ideally we should first fix CI, then rebase this PR and merge it after successful CI passes. Also could you please submit these changes to v0.2 branch as a separate PR? In it wasm code is moved to separate crates.

Pauan

comment created time in 2 months

issue commentrust-random/rand

Stop forwarding getrandom's wasm features

@benmkw Library crates should not enable getrandom features, unless they target wasm-bindgen/stdweb exclusively. And application crates can simply add the following line to their Cargo.toml:

getrandom = { version = "0.1", features = ["wasm-bindgen"] }

In getrandom v0.2 those features will be replaced with "custom" crates, so applications will use the wasm-bindgen-getrandom crate instead. By adding this crate to your dependency tree you will overwrite the panicking implementation default for unsupported platforms. In other words with rand v0.8, your application crate can simply have the following line:

[target.wasm32-unknown-unknown.dependencies]
wasm-bindgen-getrandom = "0.1"

Farther in future getrandom may get integrated into std, making it similar to alloc.

dhardy

comment created time in 2 months

issue commentTinkoffCreditSystems/invest-openapi

Streaming ограничение в 6 TCP соединений

Подтверждаю обрывы соединения со стороны сервера. Время может варьироваться от пары минут до нескольких часов. В среднем при открытых рынках обрыв происходит через 30-50 минут. Добавление пингов каждые 10-30 секунд ситуацию не поменяло. При закрытых рынках соединение продержалось более 400 минут, т.е. похоже что обрывы зависят от количества пересланных сообщений. При одновременном запуске двух идентичных процессов обрывы для них происходят в разное время, т.е. маловероятно что дело в плохом канале.

Karpik666

comment created time in 3 months

issue commentsnapview/tungstenite-rs

Allow sending of shared data

But it would work with read_message_to, correct? I think introducing an additional "reference" message type (in addition to the current "owned" one) and additional read/write methods for it is a better option compared to introducing additional message variants.

jean-airoldie

comment created time in 3 months

issue commentsnapview/tungstenite-rs

Allow sending of shared data

Can't we instead change Message to:

pub enum Message<'a> {
    Text(&'a str),
    Binary(&'a [u8]),
    Ping(&'a [u8]),
    Pong(&'a [u8]),
    Close(Option<CloseFrame<'static>>),
}

This would allow to cache messages if needed without cloning data and will allow users to remove unnecessary allocations, e.g. if messages are fixed or with if reusable buffer is used.

The same type can be used for receiving messages as well, with the following signature changes:

// this function will use an inner buffer stored inside `WebSocket` instance
pub fn read_message<'a>(&'a mut self) -> Result<Message<'a>> { .. }
// we also could add function like this
pub fn read_message_to<'a>(&mut self, buf: &'a Vec<u8>) -> Result<Message<'a>> { .. }

This would allow additional optimizations, although it may complicate code a bit (especially for async).

jean-airoldie

comment created time in 3 months

more