Hi,
Some HID devices do not list any report IDs for communication, e.g. my
Yubikey5:
> uhidev0: iclass 3/0
> uhid0 at uhidev0: input=64, output=64, feature=0
> ugen0 at uhub0 port 2 configuration 1 "Yubico YubiKey FIDO+CCID" rev
> 2.00/5.12 addr 2
on Linux, these can be talked to by sending to
On Wed, Oct 16, 2019 at 11:42:16PM +0200, Alexander Bluhm wrote:
> syszcaller shows that we lack kernel input validation when setting
> addresses.
>
> https://syzkaller.appspot.com/bug?id=4196491189556b467eafcc8daf3f9a051b4123a0
>
> Althogh this is not exactly the ioctl(2) syzcaller found, I would
Yes. But there is already some kind of mechanism implemented who does
encryption and decryption of the keydisk. But stores its own key in
metadata.
So I wonderd if I could use this already existing implementation and
extend it for my usage. Or if there is a specific reason for it doing
what it doe
Andras Farkas(deepbluemist...@gmail.com) on 2019.10.24 13:58:26 -0400:
> Diff attached, changes bad link:
> https://man.openbsd.org/OpenBSD-6.6/acme-client.5
> to
> https://man.openbsd.org/OpenBSD-6.6/acme-client.conf.5
> on this page:
> https://www.openbsd.org/faq/upgrade66.html
>
fixed, thanks
List(l...@md5collisions.eu) on 2019.10.24 21:06:27 +0200:
> Hi,
>
> in function sr_crypto_create_keys (sys/dev/softraid_crypto.c, 489):
>
> The keydisk is masked by encrypting(1) a generated random buffer.
>
> This encrypted random buffer (keydisk) is afterwards used to encrypt(2)
> the harddisk
Hi,
in function sr_crypto_create_keys (sys/dev/softraid_crypto.c, 489):
The keydisk is masked by encrypting(1) a generated random buffer.
This encrypted random buffer (keydisk) is afterwards used to encrypt(2)
the harddisk itself.
Why is it done that way ?
Would it be ok to not store this (1)
Diff attached, changes bad link:
https://man.openbsd.org/OpenBSD-6.6/acme-client.5
to
https://man.openbsd.org/OpenBSD-6.6/acme-client.conf.5
on this page:
https://www.openbsd.org/faq/upgrade66.html
Do documentation-related diffs like this belong in tech, bugs, or misc?
Index: upgrade66.html
==
On 2019/10/21 04:06, Martin Pieuchot wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: m...@cvs.openbsd.org2019/10/21 04:06:31
>
> Modified files:
> lib/librthread : synch.h
>
> Log message:
> Use process-private futexes to avoid the uvm_map lookup overhead.
>
> While he
On 2019/10/24 11:48, Paul de Weerd wrote:
> The downside of using your own resolver (e.g. by running unbound on
> your laptop), its traffic is more easily tied to a specific user.
> There's an anonymizing power in using a bigger (shared) resolver (with
> the downside that you then give your queries
On Thu, Oct 24, 2019 at 12:24:22PM +0200, Otto Moerbeek wrote:
> On Thu, Oct 24, 2019 at 11:27:24AM +0100, Kevin Chadwick wrote:
>
> >
> > > The purpose of unwind is to provide secure DNS services even when
> > > the available nameservers are broken or filtered like in many hotels.
> > > To do t
On Thu, Oct 24, 2019 at 11:27:24AM +0100, Kevin Chadwick wrote:
>
> > The purpose of unwind is to provide secure DNS services even when
> > the available nameservers are broken or filtered like in many hotels.
> > To do that, it prefers DNSSEC whenever possible and changes to do
> > resolving by
On Thu, Oct 24, 2019 at 11:27:24AM +0100, Kevin Chadwick wrote:
|
| > The purpose of unwind is to provide secure DNS services even when
| > the available nameservers are broken or filtered like in many hotels.
| > To do that, it prefers DNSSEC whenever possible and changes to do
| > resolving by i
> The purpose of unwind is to provide secure DNS services even when
> the available nameservers are broken or filtered like in many hotels.
> To do that, it prefers DNSSEC whenever possible and changes to do
> resolving by itself if needed.
>
> DNSSEC only offers integrity and authenticity. To
13 matches
Mail list logo
