HN user
That paragraph has no relevancy to the GPLv2, it is pointing out how they fixed the problem in version 3.
The Linux kernel is still licensed under GPLv2.
The differences between v2 and v3 is the entire context of this thread, so I believe you're deliberately being obtuse.
Are we reading the same thing? It says:
The best way to make sure you are in compliance when distributing GPLv2 object code on BitTorrent would be to include all the corresponding source in the same torrent
Not a link to the source, the source code itself.
My favourite part of the GPLv2 is the torrent technicality[0]. I wonder if all those people seeding Linux distributions realise they're violating the license.
Also see, Ted Unangst's post about ZFS where he lists some criticisms[0] which somewhat expands on Brauer's criticism, and he talks about when he was interviewed on BSD Now[1].
Keep in mind that their criticisms are mostly about it not being a good choice for OpenBSD, although some of them apply across the board.
[0] http://www.tedunangst.com/flak/post/ZFS-on-OpenBSD
[1] http://www.bsdnow.tv/episodes/2014_02_05-time_signatures
Go to justgetflux.com and CTRL+F for the word "patent".
Which parts of "being Firefox" did the Firefox versions in Debian stable, where the only changes were backported security patches, fail?
It's entirely inconsistent with Mozilla's past actions.
You can compile Firefox source code of which 100% of it came from released Firefox versions in Mozilla's HG tree and they won't let you call that "Firefox". Part of why IceWeasel exists is Debian wanted to backport security patches from Firefox releases into an older version (eg. apply security patches from Firefox 4 to Firefox 3.5) for Debian-stable and Mozilla wouldn't let them use the name Firefox if they did that.
Therefore your claim that
Firefox is the UI chrome and corresponding stack
doesn't match the reality of what Mozilla has done. It seems now Firefox is anything that Mozilla calls Firefox.
What Mozilla won't let you call "Firefox": a version of Firefox where the only changes are security patches backported from a future version of Firefox (see: the Debian and IceWeasel debacle).
What Mozilla will call "Firefox": a wrapper around WkWebView that uses WebKit.
The examples are just examples, the uses in the tree are different. For example, ksh doesn't exit if pledge fails, it just prints an error about why it failed and keeps running (imagine how fun it would be the shell did just keep terminating). Other programs use their own logging to report the error, for example httpd logs the error the same way it logs all other fatal errors before it exits.
I don't see how pledge is different from Capsicum which he criticises on this basis, one it is compiled in you cant disable it.
This is addressed in the slides. Capsicum is 5 years old and used in 12 programs because it is difficult to implement. Pledge is 6 months old and used in over 400 programs already.
he dismisses SE Linux on that basis. I don't see why the same doesn't apply to pledge.
If you use a Linux distro that enables SE Linux, the second it gets in the way you can turn it off. If you install OpenBSD-current right now, all those utilities use pledge and you can't just turn it off.
Theo is getting good results on tightening up the classic UNIX command line tools. Has he tried EMACS yet?
You may want to take a closer look at the slides about what has been pledged so far. httpd, smtpd, ntpd, relayd, slowcgi, xterm... They're not quite emacs, but they're also not just command line tools.
Page 19 is interesting. It explains that this is possible, without everything that does logging needing access to sockets, because on OpenBSD syslog(3) doesn't use sockets and doesn't need a file descriptor.
There is a lot more than just the useragent when it comes to Tor Browser versus any other browser. Tor Browser has many changes to try and make every instance of Tor Browser look identical, everything from the HTTP headers to window size to timing functions being rounded uniformly. Although I am guessing he browses with javascript turned off, which does defeat most of the fingerprinting techniques.
I wonder if he realises that browsing over Tor with IceCat will be causing him to have quite a distinct browser fingerprint. He should just use Tor Browser.
- Toggle layout.css.visited_links_enabled to False
Firefox lies[0] to scripts that try to access the style-state of visited links. You probably don't need to set this.
[0] https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and...
That sounds like it was written by someone who doesn't completely understand Convergence, and also has an alternative agenda (they want their own solution adopted).
It is not very user friendly. Users are asked to manage a list of notaries. This list of notaries is stored locally on the computer, or even the browser. Managing this list is not feasible for most users.
Browsers can replace the CA root certs with a notary list and pick notaries at random from the list. This is not a problem like with CAs as multiple notaries have to collude to form a consensus (you only need one rogue CA), and rogue notaries can be removed on a whim, unlike CA roots which are indentured (removing a CA breaks any site that uses it).
It's not clear how well it protects (or can protect) if some notaries haven't yet cached the latest SSL certificate for a particular website.
This doesn't matter at all. The notary looks the cert, checks the signature and tells you if it matched what you're seeing.
It does not provide MITM protection on first visit.
Yes it does. If your connection is MITM'd the notaries won't match your perspective.
Waiting for group consensus means all connections have higher latency (slower page loads).
Only the first visit, before the notaries confirm the certificate signature you're seeing, and then you cache it and only need to check it again if it changes.
Both Convergence and Perspectives (see below) results in you sharing every website you visit with random third-parties.
Bounce notaries exist for this reason.
With DNSChain, if privacy is a concern, you can run your own server and only rely on it
Same with Convergence.
The CA system is unique is that one hole, breach or incompetent actor compromises the entire system.
It's also unique is that when an authority has a hole, breach or is an incompetent actor, it's very difficult to remove them from authority.
I have no doubt that there would be incompetent or dishonest notaries. The difference being that in an alternative universe, where Convergence is used, a rogue notary doesn't destroy the trust of the entire system. When Symantec is a rogue notary, oh well, Mozilla and Google push out an update and no one uses Symantec anymore, their notary just becomes irrelevant. However, in this reality, the darkest timeline, deciding to stop trusting Symantec immediately breaks 30% of HTTPS websites on the internet, so even though Symantec has given everyone plenty of reasons to stop trusting them, we have no choice. Same for Comodo, their notary would have stopped being used in 2011 (after their root certificate compromise).
Instead, with Comodo and Symantec combined, we now have over 60% of HTTPS websites secured by authorities who are incompetent and/or dishonest.
Convergence was the perfect replacement, but it never gained any traction.
Moxie's talk at BlackHat[0] introducing it is a good watch for those unfamiliar with the idea, and if you want to be wistfully frustrated at what could have been.
It makes me uncomfortable that the CA system is set up in a way that makes this necessary. If an alternative, such as Convergence, had taken off we wouldn't be in this situation.
I used your script to sign my cert and it works great.
The best part is it doesn't need to bootstrap and try to install a bunch of dependencies that I don't want or need, unlike the official client.
Thanks a lot.
That whole discussion on the slide from 38:50 is hilarious and scary.
"You can't turn off the debugging malloc but you can turn off sockets"
"If the size of socklen_t changes while your program is running, OpenSSL will cope"
LibreSSL is mostly a drop-in replacement for OpenSSL, while BoringSSL has removed things that some applications will depend on. OSes shouldn't/couldn't replace OpenSSL for BoringSSL (the article says as much) but could replace OpenSSL with LibreSSL (some already have).
LibreSSL has had roughly half (22 to 43) as many vulnerabilities as OpenSSL since the fork and, before this, 0 sev:high, compared to OpenSSL's 5 sev:high.
Would you really disregard all that because of a 1-byte buffer overflow and a memory leak?
The problem in that thread was caused by building ports, which will fill up /usr. If you're going to build ports, I'd recommend changing the working dirs[0] to a different partition (I use /home).
Because of how the auto-partitioner decides the sizes, a 120GB disk should get the same partition sizes as a 256GB disk (the 256GB will just get more /home space). My 256GB disk has 2G each for /usr /usr/obj and /usr/src, and with that I can build kernel, userland and xenocara with no problems (unless I've filled up /usr by building Firefox from ports).
This also stores the name of the site in plain-text.
Making one big partition isn't the best idea because OpenBSD defaults the way it does for stability, data integrity and, a big surprise... security reasons[0].
That said, you shouldn't run out of space in the default partitions when building the system (ports are another story).
As far as I know the installer defaults to giving you around 2GB in /usr/src (which is more than enough to hold the source and build everything) and if the disk isn't big enough to do that, it won't partition it (60GB is big enough to get a separate /usr/src so 120GB is surely enough).
This assumes the instructions[1] are followed so everything is put in the right places and all the object files aren't dumped into the partition. Other than that, I don't know what could have went wrong.
mtier employs a couple of OpenBSD developers to do those builds.
Which language?
Haven't you been paying attention? You're supposed to write your security-critical code in a language that was released 5 months ago and has no major deployments yet.