') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); Unify the `aes`, `aesni`, `aes-ctr`, and `aes-soft` crates by tarcieri · Pull Request #200 · RustCrypto/block-ciphers · GitHub
Skip to content

Unify the aes, aesni, aes-ctr, and aes-soft crates - #200

Merged
tarcieri merged 6 commits into
masterfrom
aes/unify-crates
Nov 18, 2020
Merged

Unify the aes, aesni, aes-ctr, and aes-soft crates#200
tarcieri merged 6 commits into
masterfrom
aes/unify-crates

Conversation

@tarcieri

@tarcieritarcieri commented Nov 16, 2020

Copy link
Copy Markdown
Member

Combines all four crates into a single aes crate.

The optional ctr feature exposes a consistent set of Aes*Ctr types.

cc @peterdettman

Comment threadaes/Cargo.toml Outdated
@tarcieri
tarcieriforce-pushed the aes/unify-crates branch 6 times, most recently from 2d71c31 to 4479823CompareNovember 16, 2020 22:27
Comment threadaes/Cargo.toml Outdated
@tarcieri
tarcieriforce-pushed the aes/unify-crates branch 2 times, most recently from e79b4b6 to ec205caCompareNovember 16, 2020 22:39
Combines all three crates into a single `aes` crate.
The optional `ctr` feature exposes a consistent set of `Aes*Ctr` types
as well.
@tarcieritarcieri changed the title [WIP] Unify the aes, aesni, and aes-soft cratesUnify the aes, aesni, and aes-soft cratesNov 16, 2020
@tarcieri
tarcieri marked this pull request as ready for review November 16, 2020 22:53
@tarcieri

Copy link
Copy Markdown
MemberAuthor

I was a bit torn on whether to call this a breaking change (i.e. bumping the version to 0.7.0-pre).

It seems like the only breaking case would be treating the types exported from aes as the same as either aesni or aes-soft, which would be breaking if ever AES-NI were/weren't used (depending on what you're expecting).

Given that, I think it's safe to call it backwards compatible. We could potentially release this as v0.6.1, and yank the previous v0.6.0 to prevent any shenanigans.

@newpavlovnewpavlov left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I thought that unification is worth only with added runtime detection. Otherwise AES-NI support will be hard to find for users who do not use the aes crate directly. In other words most users will use the software implementation, while with the current implementation they may notice aes-soft in their build log. I think I've seen projects which use aesni directly to motivate users to enable the aes target feature.

But I guess if we'll add the runtime detection before the next minor cipher version, merging crate now should not be a problem.

Comment threadaes/src/lib.rs Outdated
Comment threadaes/src/lib.rs
Comment threadaes/src/ni.rs Outdated
Comment threadaes/src/ni/aes192.rs Outdated
@tarcieri

Copy link
Copy Markdown
MemberAuthor

I thought that unification is worth only with added runtime detection.

We definitely need it for that. The current target-based gating of aesni vs aes-soft crate dependencies makes adding it impossible.

But also it's unclear how to add things like ARM acceleration (#10), which is especially important given the recent launch of the Apple M1. Would that otherwise go into aesni? But then we need to gate on two different targets, and things get quite complicated. Add yet another crate? I think as we add more hardware accelerated backends, converging on a single crate makes things a lot easier.

Comment threadaes/src/ni.rs
@newpavlov

newpavlov commented Nov 18, 2020

Copy link
Copy Markdown
Member

it's unclear how to add things like ARM acceleration

AFAIK the ideal solution is blocked on rust-lang/rfcs#2725. Meanwhile we would have to either write platform-specific code to extract available features, continue to rely on RUSTFLAGS, or add a feature for forcing hardware-accelerated implementation (assuming M1 uses the AArch64 crypto extension). Considering that ARM intrinsics are still unstable, I think the latter option will be fine for now.

@tarcieri

tarcieri commented Nov 18, 2020

Copy link
Copy Markdown
MemberAuthor

Think I addressed all of the outstanding comments.

Re: cfg-if-based gating in lib.rs I mentioned earlier, I think I'd like to explore that as part of a separate PR.

An additional remaining question is still whether if this is merged, whether it could be published as v0.6.1, or if we should hold off and do a cipher crate upgrade and/or runtime detection first.

@newpavlov

Copy link
Copy Markdown
Member

I think we can merge but do not publish just yet.

@tarcieri
tarcieri merged commit cd5a34f into masterNov 18, 2020
@tarcieri
tarcieri deleted the aes/unify-crates branch November 18, 2020 15:21
tarcieri added a commit that referenced this pull request Nov 18, 2020
Bumps the `aes` crate version to indicate we'll be making breaking
changes before the next release (i.e. `cipher` crate upgrade).
Also removes the `aesni` and `aes-soft` crates from the README.md table
now that they've been unified into the `aes` crate (#200)
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@tarcieri@newpavlov