An easy to install, high-performance, zero maintenance proxy to run an encrypted DNS server.
in blake2b-ref.c I found that both salt and personal could be null.
how could I set salt without setting ctx ?
OR, blake2b has a default salt or ctx ? I tried Uint8Array filled with 0, it did not generate correct hash
The type for these parameters is
buf. I guess it should be something like
It's quite surprising to see that such type is not implemented yet, as there are other functions with nullable fixed-size buffers.
LICENSE is MIT, but
hostcalls: remove curve25159-dalek
This avoids using a deprecated crate, but also unblocks dependency issues with the zeroize and rand crates.
Add links to the meetings, and minutes from 2022-09-22
./dnscrypt-proxy -resolve example.com
Resolver : 188.8.131.52 (scaleway-fr.dnscrypt.info.) Canonical name: example.com. IPv4 addresses: 184.108.40.206 IPv6 addresses: 2606:2800:220:1:248:1893:25c8:1946 Name servers : b.iana-servers.net., a.iana-servers.net. DNSSEC signed : yes Mail servers : 1 mail servers found HTTPS alias : - HTTPS info : - Host info : - TXT records : wgyf8z8cgvm2qmxpnbnldrcltvk4xqfn, v=spf1 -all
all the time
dig ns2.domain.local A +short 192.168.122.77
Resolving any other fqdns ending with the same fqdn:
dig whateverns2.domain.local A +short 192.168.122.77
The last part should never happen!
This is expected.
= prefix is required for exact matching. See the documentation: filter patterns.
What parts of the README file would benefit from more verbose documentation?
DNSCrypt may be easier to setup (see https://github.com/DNSCrypt/encrypted-dns-server - there's also a docker image). And if the intent is to bypass a country's restrictions, it makes way more sense than DoH due to its instant support for anonymization.
The crate README.md says there is Formal verification -
I'm sending a PR there - do we have a link to the formal verification report we can refer to please ?
According to the Xcode 14 release notes:
Xcode builds for watchOS devices now include the arm64 architecture by default. (83319300)
As a result adding swift-sodium to a watchOS target fails during the Archive step due to missing arm64 architecture.
Here's how I validated - I ran ./apple-xcframework.sh, switched out the xcframework in swift-sodium for this one, tested for watchOS, successfully built.
This is not a bug per se. I'm not even entirely sure what the correct action is in this case, but I thought I'd mention it anyway. With versions
1.0.13 and onward, a new feature
signatures was introduced. AFAIU, this constitutes a minor SemVer version bump, according to API Evolution RFC. I'd have though this would require a
1.1.x version, instead.
Feel free to close this @jedisct1, if this was intentional.
In case anyone else had their
ed25519-compact on non-default-features, pulled in signature-related types and their build broke: this can be fixed by adding
"signatures" to selected features of this crate.
Backward compatibility feels more important.
To some extent
opt_size also removes something.
Version 1.0.15 was released to fix this.
Oh, indeed, thanks!
I guess a better way would be to have a "disable-signatures" feature instead.