Recent comments on posts in the blog:

workaround

You can edit /var/cache/debconf/config.dat manually instead, but be aware that you can really break things by editing this.

The file it uses for configuration is defined in /etc/debconf.conf, should it not be where you expect on your system

# World-readable, and accepts everything but passwords.
Name: config
Driver: File
Mode: 644
Reject-Type: password
Filename: /var/cache/debconf/config.dat
Comment by draeath
what about auto-discovery?

i also wonder if we could get this simplified somehow. i don't mind configuring the server so much, but it's kind of painful to have to edit config files by hand on each client that needs to be configured...

can't Avahi take care of this for us, just like it does for CUPS and printing? i looked around for this feature but so far all I've found are bug reports saying that it doesn't work (ubuntu LP#508866, debian #743420). and indeed, with SANE_DEBUG_NET=128 scanimage -L says:

[net] sane_get_devices: local_only = 0
[net] sane_get_devices: finished (0 devices)
[net] net_avahi_browse_callback: CACHE_EXHAUSTED
[net] net_avahi_browse_callback: ALL_FOR_NOW

No scanners were identified.

So I'm not sure what's going on, but clearly this is not working...

Comment by anarcat
why network and central docs

i setup a network scanner here because it is also a printer and already connected, by USB, to a print server so that many people can print on it without having to worry about cabling.

yes, they need to move their feet to get actual paper in and out of there. crazy physics. but it beats fiddling with wires. :)

also i figured i would mention there is a similar guide in the Debian wiki - which seems to have slightly better SEO, so it comes up first. Therefore, I have reworked it to include the excellent suggestions here that were missing there. See if you can improve it further! :)

Comment by anarcat
Taking a sledgehammer to an egg?

That pwned list of a password is a fantastic resource. Thanks for posting a pointer to it.

But Egad! - using postgres to index and search it?? You must have the patience of a saint.

Given a false positive isn't a death sentence, a bloom filter is a better choice. Setting the parameters to give a false positive range of 1e-9 (roughly 50/50 chance of getting 1 false positive if I checked a password with it every second for my entire life), the resulting filter occupies 2.6G - about 1/2 the size of the compressed original. Creating the filter takes about 3 hours on my laptop (please forgive the butt ugly inline python):

sudo apt-get install python, python-pybloomfilter
wget http://.../pwned-*.txt.7z; for f in *.7z; do 7z x $f; done
python -c "import pybloomfilter, sys; b = pybloomfilter.BloomFilter(500000000, 0.000000001, 'pwned.bf'); [b.update(open(f)) for f in sys.argv[1:]]" pwned-passwords-*.txt

Querying it:

python -c 'import hashlib,sys,pybloomfilter; b = pybloomfilter.BloomFilter.open("pwned.bf"); sys.stdout.write("".join("%s is pwned: %r\n" % (p, hashlib.sha1(p).hexdigest().upper() + "\r\n" in b) for p in sys.argv[1:]))' password1 password2 ...
Comment by Russell Stuart
magnet URL for data
If it helps, I can vouch that this torrent magnet URL corresponds to the initial release of the password list. I found it the most convenient way to obtain the data. magnet:?xt=urn:btih:88145066d8d89cf426a22cfbeb1983dacb2a45d7&dn=pwned-passwords-1.0.txt.7z&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fopen.demonii.com%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Fexodus.desync.com%3A6969
Comment by Jonathan
Question

This command: git push /tmp/myrepo.git master

Seems to be pushing an empty repo. What am I missing?

You touched a file in myrepo1, correct?

Second: Don’t you need to specify the origin of myrepo1? Before pushing it?

Comment by Anonymous
Followup:

Thanks to this discussion, i just opened a bug report on irssi to try to resolve the second issue above by sending client certificates in a renegotiated handshake.

I've tested irssi, and it definitely does leak the user's public certificate to a passive network monitor.

I haven't tested ZNC yet -- If someone wanted to open a similar report for ZNC, i'd appreciate it.

If you want to test to see whether it's dumping traffic, you can do this with tshark:

tshark -O ssl  -Y 'ssl.handshake.certificates_length > 1 && ssl.record.content_type == 22'  -o http.ssl.port:6697 port 6697

I don't have a patch to propose for either irssi or ZNC yet, and don't have much time to work on it myself. I'd be happy to see that happen, because it would remove one of the major downsides to using certificates for IRC.

Comment by Daniel Kahn Gillmor
problems with certificate-based TLS authentication for IRC

I used to use this approach myself, but i stopped using it a few years ago, for two reasons:

  • certificate expiration -- when my registered certificate expires, i still need to update the server with my new certificate. to do that, i need my password. so my password still works, and i still have to retain it and send it to (what i hope is the correct) nickserv service at each cert renewal time. so this doesn't actually remove either my needing to remember/retain/record a password, and it doesn't make my remembered/recorded password less powerful.

  • client certificate leakage -- in TLS versions 1.2 and earlier (all deployed versions of TLS), the client certificate is exchanged in the clear, during the handshake. (TLS 1.3 will fix this, but it is not yet fully standardized or in deployed production). This means that client cert authentication actually leaks your identity to any passive network observer, whereas password-based authentication to nickserv does not.

This pains me, because i generally strongly prefer pubkey-based authentication over password-based authentication. But in this case, i think it's not enough of a win overall to make the transition.

What do you think about these tradeoffs? Are there mitigating factors that i should know about that makes them less troubling?

Comment by Daniel Kahn Gillmor
Solution

I figured it out.

In order for OpenVPN to use the locally installed Unbound DNS resolver, do this:

First check for the IP we should use with: sudo ifconfig

The IP we need is the one listed at

tun0: inet 10.8.0.1

UNBOUND

Add this to /etc/unbound/unbound.conf:

server:
    interface: 127.0.0.1
    interface: 10.8.0.1
    access-control: 127.0.0.1 allow
    access-control: 10.8.0.1/24 allow

Then restart Unbound with: sudo service unbound restart

Test with: dig @10.8.0.1 google.com

(SERVER should read: SERVER: 10.8.0.1#53(10.8.0.1))

OPENVPN

Add this to (or modify) /etc/openvpn/server.conf:

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.8.0.1"
push "register-dns"

Then restart OpenVPN with: sudo service openvpn restart

OpenVPN clients should now be using Unbound. Test at http://dnsleak.com/.

Eldin Hadzic eldinhadzic@protonmail.com

Comment by Eldin Hadzic