profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/Geal/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

CleverCloud/lapin 585

AMQP client library in Rust, with a clean, futures based API

Geal/cargo-external-doc 33

integrate markdown files with your rustdoc generated documentation

Geal/cargo-plugin 7

compile time plugins for your Rust projects

Geal/archlinux-pharo-image 3

Docker image for Pharo Smalltalk

Geal/bittorrent 2

Rust implementation of the BitTorrent Protocol: http://www.bittorrent.org/beps/bep_0003.html

Geal/build-metadata 2

embed repository metadata in your code at compile time

dignifiedquire/smol 1

A small and fast async runtime for Rust

issue commentsozu-proxy/sozu

Drop old connections when the accept queue is full

This should have a config option : if someone tried to create a lot of new connections to kill the server, this option would drop inactive but legitimate connections, we might not want that depending on the kind of server

BlackYoup

comment created time in 3 hours

issue commentCleverCloud/biscuit

ECDSA support

I'm wondering how that would play out with attenuation, where a new signature has to be made. Here are the possible scenarios:

  • the signing algorithm can change on every block (ECDSA on one, Ed25519 on the next, etc). We would need a way to signal which algorithm should be used for the next signature (since the previous block chooses the key pair), and which algorithms should be used to verify each block, otherwise we'd try to verify a signature on P256 with the Ed25519 algorithm(are there possible issues when confusing curve algorithms there?). Unless there's a way from looking at the keys or signature to guess which kind they are?
  • the signing algorithm is the same for the entire token. We still need a way to signal it. It can be done with a field like the root key id. That field does not need to be signed: the verifier could check that it matches the chosen root key

Apart from that field, the format would not change, keys and signatures are just byte arrays.

About the implementaton mistakes, do you think we can mandate the safer ways to sign?

tarcieri

comment created time in 16 hours

issue commentsozu-proxy/sozu

"lifetime of a session" documentation

You can restart grom the presentation, I have not advanced on it

Geal

comment created time in a day

pull request commentsozu-proxy/sozu

remove dead code

It should be the max number of slab elements, but:

  • each socket listener takes one slab element
  • a HTTP 1 session takes 1 or 2 slab elements
  • a HTTP 2 session could take more than 2 slab elements

So the value will never be extremely precise, it depends on the usage

Keksoj

comment created time in a day

pull request commentsozu-proxy/sozu

remove dead code

This should not be removed: I deactivated it when refactoring the sessions but did not have the time to reactivate it.

The behaviour should be:

  • if we reach the connection limit, stop accepting new connections and flush the accept queue, to signal quickly to clients that they should reconnect elsewhere
  • wait until we recover some capacity before accepting again (otherwise it will spend its time stopping then accepting again)
Keksoj

comment created time in a day

issue commentrustls/rustls

KTLS Support

So I guess the two plans are:

  • integrate ktls in rustls and create a TcpStream from a session and a file descriptor
  • expand KeyLog to provide the sequence ids and IV, and implement ktls in another crate

What was the original purpose of KeyLog? Debug, or decryption elsewhere in the infra?

quininer

comment created time in a day

issue openedsozu-proxy/sozu

rustls proxy might be broken

While testing 0.14 with rustls, I encounter this error on every HTTPS request (with trace level logs):

2021-September-23T09:07:27.070263Z 1632388047070263293 2027840 WRK-00 TRACE     sozu_lib::timer inserted timeout; slot=121; token=Token(0)                  
2021-September-23T09:07:27.071405Z 1632388047071405896 2027840 WRK-00 TRACE     sozu_lib::tls   trying to resolve name: "unhandledexpression.com" for signature scheme: [ECDSA_NISTP256_SHA256, RSA_PSS_SHA256, RSA_PKCS1_SHA256, ECDSA_NISTP384_SHA384, RSA_PSS_SHA384, RSA_PKCS1_SHA384, RSA_PSS_SHA512, RSA_PKCS1_SHA512]                                                                                                                                                        
2021-September-23T09:07:27.071876Z 1632388047071876442 2027840 WRK-00 TRACE     sozu_lib::tls   looking for certificate for "unhandledexpression.com" with fingerprint CertificateFingerprint(502176ef7ffb1a53cabb5cf484414c348a88af0347e1cd367ad7a237bb8be282)                                                         
2021-September-23T09:07:27.090921Z 1632388047090921966 2027840 WRK-00 TRACE     sozu_lib::https_rustls::session front readable  interpreting session order Continue                                                                                                                                                     
2021-September-23T09:07:27.091019Z 1632388047091019224 2027840 WRK-00 TRACE     sozu_lib::https_rustls::session PROXY    Token(5) F:Readiness { interest: RWEH, readiness: -W--, mixed: -W-- } B:None                                                                                                                   
2021-September-23T09:07:27.091170Z 1632388047091170408 2027840 WRK-00 TRACE     sozu_lib::https_rustls::session front writable  interpreting session order Continue                                                                                                                                                     
2021-September-23T09:07:27.091220Z 1632388047091220591 2027840 WRK-00 TRACE     sozu_lib::https_rustls::session PROXY    Token(5) F:Readiness { interest: R-EH, readiness: -W--, mixed: ---- } B:None                                                                                                                   
2021-September-23T09:07:27.114857Z 1632388047114857397 2027840 WRK-00 TRACE     sozu_lib::server        PROXY   Token(5) got events: Readable | Writable    
2021-September-23T09:07:27.114956Z 1632388047114956910 2027840 WRK-00 TRACE     sozu_lib::https_rustls::session token Token(5) got event RW--               
2021-September-23T09:07:27.115026Z 1632388047115026041 2027840 WRK-00 TRACE     sozu_lib::https_rustls::session PROXY    Token(5) F:Readiness { interest: R-EH, readiness: RW--, mixed: R--- } B:None                                                                                                                   
2021-September-23T09:07:27.115086Z 1632388047115086844 2027840 WRK-00 TRACE     sozu_lib::timer unlinking timeout; slot=121; token=Token(0)                 
2021-September-23T09:07:27.115139Z 1632388047115139294 2027840 WRK-00 TRACE     sozu_lib::timer setting timeout; delay=Duration { seconds: 12, nanoseconds: 100697728 }; tick=121; current-tick=22                                                                                                                      
2021-September-23T09:07:27.115189Z 1632388047115189633 2027840 WRK-00 TRACE     sozu_lib::timer inserted timeout; slot=121; token=Token(0)                  
2021-September-23T09:07:27.115365Z 1632388047115365034 2027840 WRK-00 ERROR     TLS alert received: Message {                                               
    typ: Alert,                                                                                                                                             
    version: TLSv1_3,                                                                                                                                       
    payload: Alert(                                                                                                                                         
        AlertMessagePayload {                                                                                                                               
            level: Fatal,                                                                                                                                   
            description: CertificateRequired,                                                                                                               
        },                                                                                                                                                  
    ),                                                                                                                                                      
}                                                                                                                                                           
2021-September-23T09:07:27.115526Z 1632388047115526526 2027840 WRK-00 ERROR     could not perform handshake: AlertReceived(CertificateRequired)             

Apparently the certificate is correctly looked up by the resolver, but still not used by rustls in the handshake

created time in a day

pull request commentGeal/nom

[WIP] Feature multi range

Hey! I'm sorry I have not had the time to review this yet, I'll try to take a look on Thursday or Friday? In the meantime, could we put a pin on it and cool off the discussion?

cenodis

comment created time in 2 days

issue commentrustls/rustls

KTLS Support

so, after looking a bit more into it, I have a rough plan. For some context: the way KTLS works is that the userland TLS implementation performs the handshake, then a KTLS file descriptor is created, then the IV, keys and sequence ids are extracted from the TLS session, and added to the KTLS fd (see https://github.com/quininer/ktls/blob/master/src/sys/mod.rs#L40-L62 ). Then read(), write() can be called directly on this fd.

We want to avoid making rustls session secrets easily accessible, so the idea would be to transform a ClientSession or ServerSession and the associated socket into a KtlsStream, which would be provided by rustls too, so the secrets can be transmitted and set up directly, with no easy access.

Possible issues:

  • Linux only (I have not looked yet into FreeBSD's ktls implementation)
  • limited cipher suites
  • in async reactors like tokio or async-std, that rely on epoll, I think the new socket does not need to be registered to the epoll implementation, but I am not sure yet. If reading from the ktls fd consumes everything from the TCP socket's buffer, the kernel should understand that we want to read again? How do we tell the executor which task should be waked? The solution might be to register the ktls fd to epoll. This will require some tests
  • who owns which file descriptors, should we forget about the socket's fd after transforming it to a ktls fd?

By reusing the previous ktls proof of concept, I should be able to have a test up and running quickly, if that scheme looks fine. WDYT @djc ?

quininer

comment created time in 2 days

issue openedsozu-proxy/sozu

error when replacing a certificate with ACME

I was updating sozu-acme to sozu 0.14 and encountered an issue with the new certificate resolver.

Apparently when sending a ReplaceCertificate message, I get the following error:

2021-September-22T08:01:08.658111Z 1632297668658111892 1997907 MAIN DEBUG       sozu::command   worker 0 replied message: ProxyResponse { id: "ID-rjFqWb-worker-0", status: Error("failed to handle certificate request, got a resolver error, certificate is still in use"), data: None }                                                                                                                     
2021-September-22T08:01:08.658355Z 1632297668658355391 1997907 MAIN DEBUG       sozu::command   worker 0 sent back ProxyResponse { id: "ID-rjFqWb-worker-0", status: Error("failed to handle certificate request, got a resolver error, certificate is still in use"), data: None }                                                                                                                            
2021-September-22T08:01:08.660449Z 1632297668660449250 1997907 MAIN DEBUG       sozu::command   removing client CL-0                 

Since the replace operation is currently done with a remove then add, it makes sense that an error would be returned, so replacing certificates should be implemented separately

created time in 2 days

issue commentsozu-proxy/sozu

BorrowMutError on 0.14 branch

fixed in c2ad84ab48

Geal

comment created time in 2 days

issue closedsozu-proxy/sozu

BorrowMutError on 0.14 branch

Just saw that on my server, a double borrow happens when closing sessions because a timeout triggered:

thread 'main' panicked at 'already borrowed: BorrowMutError', lib/src/http.rs:774:32                                                 
stack backtrace:                                                                                                                     
   0:     0x560e2f3dcc33 - std::backtrace_rs::backtrace::libunwind::trace::ha0ad43e8a952bfe7                                         
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/../../backtrace/src/backtrace/libun
wind.rs:90:5                                                                                                                         
   1:     0x560e2f3dcc33 - std::backtrace_rs::backtrace::trace_unsynchronized::h6830419c0c4130dc                                     
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/../../backtrace/src/backtrace/mod.r
s:66:5                                                                                                                               
   2:     0x560e2f3dcc33 - std::sys_common::backtrace::_print_fmt::h8f3516631ffa1ef5                                                 
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/sys_common/backtrace.rs:67:5       
   3:     0x560e2f3dcc33 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he1640d5f0d93f618      
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/sys_common/backtrace.rs:46:22      
   4:     0x560e2f0c70dc - core::fmt::write::h88012e1f01caeebf                                                                       
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/fmt/mod.rs:1115:17                
   5:     0x560e2f3dab34 - std::io::Write::write_fmt::h360fa85b30182555                                                              
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/io/mod.rs:1665:15                  
   6:     0x560e2f3dbdab - std::sys_common::backtrace::_print::ha1f00492f406a015                                                     
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/sys_common/backtrace.rs:49:5       
   7:     0x560e2f3dbdab - std::sys_common::backtrace::print::hd54561b13feb6af3                                                      
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/sys_common/backtrace.rs:36:9       
   8:     0x560e2f3dbdab - std::panicking::default_hook::{{closure}}::h84fe124cd0864662                                              
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:208:50                
   9:     0x560e2f3dafbf - std::panicking::default_hook::h5a8e74a76ce290a7                                                           
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:225:9                 
  10:     0x560e2f3da9f0 - std::panicking::rust_panic_with_hook::h67c812a4fe9d4c91                                                   
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:626:17                
  11:     0x560e2f3f4bd8 - std::panicking::begin_panic_handler::{{closure}}::h33f9c1b96af300d7                                       
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:519:13                
  12:     0x560e2f3f4b4c - std::sys_common::backtrace::__rust_end_short_backtrace::h51bae64be5921f0e                                 
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/sys_common/backtrace.rs:141:18     
  13:     0x560e2f3f4afd - rust_begin_unwind                                                                                         
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:515:5                 
  14:     0x560e2edfb9d0 - core::panicking::panic_fmt::h12a3a3c256485fca                                                             
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/panicking.rs:92:14                
  15:     0x560e2edfbd02 - core::result::unwrap_failed::h2d8d0952e3250de9                                                            
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/result.rs:1599:5                  
  16:     0x560e2f270613 - core::result::Result<T,E>::expect::hd33b40724693ee70                                                      
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/result.rs:1241:23                 
  17:     0x560e2f270613 - core::cell::RefCell<T>::borrow_mut::h7d535b52bf2c546d                                                     
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/cell.rs:920:9                     
  18:     0x560e2f270613 - sozu_lib::http::Session::close_backend::h0e2b7d29c58a805b                                                 
                               at /home/geal/dev/sozu/lib/src/http.rs:774:17                                                         
  19:     0x560e2f26e74e - <sozu_lib::http::Session as sozu_lib::ProxySession>::close::hb7ab9449c76e1657                             
                               at /home/geal/dev/sozu/lib/src/http.rs:1142:9                                                         
  20:     0x560e2f271902 - <sozu_lib::http::Session as sozu_lib::ProxySession>::timeout::h012215ae3e47d8a0                           
                               at /home/geal/dev/sozu/lib/src/http.rs:1196:13                                                        
  21:     0x560e2f2c6618 - sozu_lib::server::Server::timeout::hbb3b0618d1e6bf55                                                      
                               at /home/geal/dev/sozu/lib/src/server.rs:1667:13                                                      
  22:     0x560e2f2b8d09 - sozu_lib::server::Server::run::hccd9d47f9d792f05                                                          
                               at /home/geal/dev/sozu/lib/src/server.rs:640:25                                                       

closed time in 2 days

Geal

issue commentrustls/rustls

KTLS Support

maybe this could be done by integrating https://github.com/quininer/ktls inside rustls? Then having ServerSession convert to it?

quininer

comment created time in 3 days

push eventsozu-proxy/sozu

Geoffroy Couprie

commit sha c2ad84ab48aebeeb8b1f409797c45e0272b5b09c

do not borrow the sessions slab while calling a session timeout timeouts can trigger session closing so they need access to the sessions slab to remove entries fix #711

view details

push time in 3 days

create barnchsozu-proxy/sozu-acme

branch : 0.14

created branch time in 3 days

issue openedsozu-proxy/sozu

BorrowMutError on 0.14 branch

Just saw that on my server, a double borrow happens when closing sessions because a timeout triggered:

thread 'main' panicked at 'already borrowed: BorrowMutError', lib/src/http.rs:774:32                                                 
stack backtrace:                                                                                                                     
   0:     0x560e2f3dcc33 - std::backtrace_rs::backtrace::libunwind::trace::ha0ad43e8a952bfe7                                         
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/../../backtrace/src/backtrace/libun
wind.rs:90:5                                                                                                                         
   1:     0x560e2f3dcc33 - std::backtrace_rs::backtrace::trace_unsynchronized::h6830419c0c4130dc                                     
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/../../backtrace/src/backtrace/mod.r
s:66:5                                                                                                                               
   2:     0x560e2f3dcc33 - std::sys_common::backtrace::_print_fmt::h8f3516631ffa1ef5                                                 
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/sys_common/backtrace.rs:67:5       
   3:     0x560e2f3dcc33 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he1640d5f0d93f618      
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/sys_common/backtrace.rs:46:22      
   4:     0x560e2f0c70dc - core::fmt::write::h88012e1f01caeebf                                                                       
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/fmt/mod.rs:1115:17                
   5:     0x560e2f3dab34 - std::io::Write::write_fmt::h360fa85b30182555                                                              
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/io/mod.rs:1665:15                  
   6:     0x560e2f3dbdab - std::sys_common::backtrace::_print::ha1f00492f406a015                                                     
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/sys_common/backtrace.rs:49:5       
   7:     0x560e2f3dbdab - std::sys_common::backtrace::print::hd54561b13feb6af3                                                      
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/sys_common/backtrace.rs:36:9       
   8:     0x560e2f3dbdab - std::panicking::default_hook::{{closure}}::h84fe124cd0864662                                              
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:208:50                
   9:     0x560e2f3dafbf - std::panicking::default_hook::h5a8e74a76ce290a7                                                           
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:225:9                 
  10:     0x560e2f3da9f0 - std::panicking::rust_panic_with_hook::h67c812a4fe9d4c91                                                   
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:626:17                
  11:     0x560e2f3f4bd8 - std::panicking::begin_panic_handler::{{closure}}::h33f9c1b96af300d7                                       
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:519:13                
  12:     0x560e2f3f4b4c - std::sys_common::backtrace::__rust_end_short_backtrace::h51bae64be5921f0e                                 
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/sys_common/backtrace.rs:141:18     
  13:     0x560e2f3f4afd - rust_begin_unwind                                                                                         
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:515:5                 
  14:     0x560e2edfb9d0 - core::panicking::panic_fmt::h12a3a3c256485fca                                                             
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/panicking.rs:92:14                
  15:     0x560e2edfbd02 - core::result::unwrap_failed::h2d8d0952e3250de9                                                            
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/result.rs:1599:5                  
  16:     0x560e2f270613 - core::result::Result<T,E>::expect::hd33b40724693ee70                                                      
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/result.rs:1241:23                 
  17:     0x560e2f270613 - core::cell::RefCell<T>::borrow_mut::h7d535b52bf2c546d                                                     
                               at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/cell.rs:920:9                     
  18:     0x560e2f270613 - sozu_lib::http::Session::close_backend::h0e2b7d29c58a805b                                                 
                               at /home/geal/dev/sozu/lib/src/http.rs:774:17                                                         
  19:     0x560e2f26e74e - <sozu_lib::http::Session as sozu_lib::ProxySession>::close::hb7ab9449c76e1657                             
                               at /home/geal/dev/sozu/lib/src/http.rs:1142:9                                                         
  20:     0x560e2f271902 - <sozu_lib::http::Session as sozu_lib::ProxySession>::timeout::h012215ae3e47d8a0                           
                               at /home/geal/dev/sozu/lib/src/http.rs:1196:13                                                        
  21:     0x560e2f2c6618 - sozu_lib::server::Server::timeout::hbb3b0618d1e6bf55                                                      
                               at /home/geal/dev/sozu/lib/src/server.rs:1667:13                                                      
  22:     0x560e2f2b8d09 - sozu_lib::server::Server::run::hccd9d47f9d792f05                                                          
                               at /home/geal/dev/sozu/lib/src/server.rs:640:25                                                       

created time in 4 days

MemberEvent

pull request commentrust-lang/rfcs

Cargo alternative registry auth

Biscuit would indeed fit well in that model: instead of registering a public key over to the registry, the registry gives a token validated by its own root key, giving access to your crates. Before any request, the credential process would attenuate (create a new token with less rights) that token to add an expiration date and bind it to the URL. The server does not need to look up a key, only validate the token (and check revocation ids).

Biscuit 2.0 should be released soon, only cosmetics change remain. The various implementation status: Rust (2.0 done, not released yet), Go (1.0), Java (in progress on 2.0), Haskell (2.0), Swift (in progress on 2.0) and C bindings to the Rust library.

I'd be happy to help adapt it in registries, otherwise yes, Paseto would work :)

arlosi

comment created time in 9 days

push eventCleverCloud/biscuit-java

Geoffroy Couprie

commit sha ba4d59edba460d3d42507e8a45f68b15ce651e62

new cryptographic scheme

view details

push time in 9 days

PR opened CleverCloud/biscuit-java

WIP: 2.0
+434 -794

0 comment

15 changed files

pr created time in 10 days

create barnchCleverCloud/biscuit-java

branch : 2.0

created branch time in 10 days

issue commentCleverCloud/biscuit

Biscuit 2.0

Still missing for this release:

  • adding a separating character in fact names to help in namespacing things (cc @meh), like module::fact("data"). The character would have no real meaning for datalog execution, it's mainly for the UX
  • specifying the accepted characters in strings: authorize tabs, unicode characters (with escapes)
Geal

comment created time in 12 days

issue commentCleverCloud/biscuit

Biscuit 2.0

rename ID to Term (this has always been confusing):

  • spec: https://github.com/CleverCloud/biscuit/commit/6c9f12d4b6de16adfbbc102f868a7a2ce2f0920b
  • Rust: https://github.com/CleverCloud/biscuit-rust/commit/a32425ab6dedb0be954b73d17a8fe28dda07713b
Geal

comment created time in 12 days

push eventCleverCloud/biscuit

Geoffroy Couprie

commit sha 6c9f12d4b6de16adfbbc102f868a7a2ce2f0920b

rename ID to Term in the protobuf schema

view details

push time in 12 days

push eventCleverCloud/biscuit-rust

Geoffroy Couprie

commit sha a32425ab6dedb0be954b73d17a8fe28dda07713b

rename ID to Term in the protobuf schema

view details

push time in 12 days

push eventCleverCloud/biscuit-rust

Geoffroy Couprie

commit sha 761c25c519fbcba5b3c7db0d89c6242e84f53289

rename ID to Term in the protobuf schema

view details

push time in 12 days

push eventCleverCloud/biscuit-rust

Geoffroy Couprie

commit sha a53f906dd724208574625392d861ba8208ffe605

add a set() method to Fact

view details

Geoffroy Couprie

commit sha 2ae46e5d3f350225d8b13030e79eaaa8c428f5fb

do not convert variables if we're not build facts or queries the builder structures are used in multiple ways: to build Datalog elements to be added to a block, to convert from a token to datalog engine with symbol table manipulations, and to extract data from the datalog engine with verifier queries. Setting variables is only useful in the first case, not the other ones (we will not set variables on immutables data from the token, nor on facts obtained from queries), so they should not bear the performance cost of going through all the elements and replacing the variables. In those cases, the variables map is not present

view details

push time in 12 days

push eventCleverCloud/biscuit-rust

Geoffroy Couprie

commit sha 507620914a1014f383219ecdf42778b9d220dda4

parse a BlockBuilder from a string With this we can define an entire BlockBuilder from one piece of source code, without doing a method call per fact, rule or check

view details

push time in 13 days

push eventCleverCloud/biscuit-rust

Geoffroy Couprie

commit sha a665fad2291c290856abedcc849bf5093aa4f829

rename things

view details

Geoffroy Couprie

commit sha 17d359d69ad31c4584cc2eb0f3da345d325709fb

From implementations for Term

view details

Geoffroy Couprie

commit sha b519da0863573bfb3abf286017ce79981c64e5b4

add a set() method to Rule, Check and Policy this method is used to replace a variable with a term. This way, a builder object can be used as a kind of prepared statement, for which the value will be replaced correctly, without relying on string interpolation

view details

Geoffroy Couprie

commit sha 175b575cd4c193a6660afa514ac28e806d2e0ed3

fix a benchmark

view details

push time in 13 days

push eventCleverCloud/biscuit-rust

Geoffroy Couprie

commit sha 580f82a376f68470740aaf74afb03d8106df3a15

update dependencies

view details

Geoffroy Couprie

commit sha 06fb4101755d2c21e30dab3a0ca263f6c6c39169

update the README

view details

Geoffroy Couprie

commit sha 89f2591b19d33bc29428fb61a8bd64457c55c9bc

fix the C API

view details

Geoffroy Couprie

commit sha 4f34a941347c4e901377b089b5b0ee69e7a583db

fix benchmarks

view details

push time in 15 days