revasm

Not a lie: I have never encountered the name Lexi before. I would have assumed it to be a made-up pseudonym. Or a reference to a post-modern sci-fi / futuristic book.

If it's short for "Alexis," which is a claim you edited out of your comment, then I'm even more confused, as that name seems to be male preferred within the US.

It doesn't scale, as the above spec points out. Pinning could be used to eliminate CAs (as most people initially expect) but this isn't viable at the moment. The specification, which proposes a method to validate the certificate chain, also accomplishes very little: it's fully vulnerable to MITM attacks on the first client connection. There are also privacy concerns about storing pinning data; and a browser which is configured to clear all data at exit would not see any benefit.

It's also wrong to say that public key pinning (which addresses PKI/TLS weaknesses) makes DNSSEC redundant. I suppose the proper comparison would be to the (optional) DANE?

Public key pinning seems to be heading in a direction that relies on the current CA model. For example, see https://tools.ietf.org/html/draft-ietf-websec-key-pinning-20, or https://code.google.com/p/chromium/codesearch#chromium/src/n... (Chrome's pinned certificate list -- which has a total of _9_ non-CA entries).

This error is caused by a bug[1] present on outdated versions of Linux (typically exhibited by DD-WRT and Tomato routers) and can also be fixed by upgrading to OpenWRT.

Or, if that is not an option, by creating an ip6tables rule:

  ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor-solicitation -i `nvram get wan0_ifname` -d ff02::1:ff00:0/104 -j DROP

Or you can experiment with the ARP cache limits:

  sysctl net.ipv6.neigh.default.gc_thresh1=256
  sysctl net.ipv6.neigh.default.gc_thresh2=512
  sysctl net.ipv6.neigh.default.gc_thresh3=1024

[1] http://serverfault.com/a/461053

Full instructions for reference. Run:

  wget http://us.archive.ubuntu.com/ubuntu/pool/main/n/nss/libnss3{_3.16.3-1ubuntu1_amd64,-1d_3.16.3-1ubuntu1_amd64,-nssdb_3.16.3-1ubuntu1_all}.deb
  sudo dpkg -i libnss3*.deb

Create a new Tampermonkey script:

  // ==UserScript==
  // @name         Netflix HTML5 for Linux
  // @namespace    0d0a3443-cc79-4f86-bf62-2dac581d2b3a
  // @version      0.1
  // @description  Enables HTML5 video support for the Linux host platform
  // @match        *://www.netflix.com/WiPlayer?*
  // @user-agent   Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.68 Safari/537.36
  // ==/UserScript==

> the passwords themselves would still be gpg encrypted, thus safe, but the repository will leak names of all websites and userIDs.

Consider encrypting the filenames with Fuse+EncFS. This flaw is pretty huge elsewise; it's why I changed to using gnupg.vim+SublimeGPG.

The problem with in-browser password management is that the attacker does not need to escape the browser. Code injection (via XSS or a browser exploit) into a running extension is likely easier than defeating the seccomp-IPC implementation or the AppArmor/SELinux profiles which protect the system. Addons like LastPass are mainly concerned with remote server weaknesses, but nothing will protect the browser from itself.

Another opinion: It's weird loading a browser+environment for non-browser passwords (SSH, HTTP/WebDAV, etc), and it's equally weird managing the passwords separately.

No:

  Note: The Strict-Transport-Security header is ignored by the browser when your site is
  accessed using HTTP; this is because an attacker may intercept HTTP connections and
  inject the header or remove it.  When your site is accessed over HTTPS with no
  certificate errors, the browser knows your site is HTTPS capable and will honor the
  Strict-Transport-Security header.

https://developer.mozilla.org/en-US/docs/Security/HTTP_Stric...

Also read RFC 6797, section 7.2 in particular.

  An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over
  non-secure transport.

and

  If an HSTS Host receives an HTTP request message over a non-secure
  transport, it SHOULD send an HTTP response message containing a
  status code indicating a permanent redirect, such as status code 301
  (Section 10.3.2 of [RFC2616]), and a Location header field value
  containing either the HTTP request's original Effective Request URI
  (see Section 9 ("Constructing an Effective Request URI")) altered as
  necessary to have a URI scheme of "https", or a URI generated
  according to local policy with a URI scheme of "https".

https://tools.ietf.org/html/rfc6797

I'm quite stumped why there aren't more good password tools. Pass, vim-gnupg, and SublimeGPG are all I've found. The application managers are atrocious -- not only the UIs but data format interoperability as well. Browser managers are insane.

On another note, the pass documentation recommends a filesystem layout that doesn't remember usernames. I used this scheme before going back to vim:

  www-website-com/id/username
  www-website-com/id/password
  www-website-com/id/other_field

Yeah. It could be problematic. Then again, 6to4/6in4 tunneling is fairly straightforward: https://en.wikipedia.org/wiki/List_of_IPv6_tunnelbrokers. Binding to a backup IPv4 port is another option.

I connect to many SSH servers that aren't under my control. It's pretty annoying to remember an arbitrary SSH port for my own.

Binding to IPv6-only is more effective at reducing log spam: IP scanning 2^128 addresses is impractical, and scanners often cannot connect because of misconfiguration/incompatibility or lack of a routable IPv6 host address.

That was an unfortunate example. The widen() in this case is absolutely unnecessary. The author even recommends using the L prefix for UTF-16 string literals inside of Windows API calls (but not on other platforms, where wchar_t isn't UTF-16):

> Do not use _T("") or L"" literals in any place other than parameters to APIs accepting UTF-16.

Except for that, you do make a good point. It's probably better to store some strings in memory according to the platform requirements, if the program can be shown to exhibit delays caused by string conversions.

The parent poster is talking about static linking against a third-party LGPL library, not your own library. In such a case, failing to provide the complete source code, or the original compilation dependencies (.o, .a, .so) and the build chain, is very much against the LGPL.

(Edit: I can't seem to quote the LGPL section 4, so here is a link to it: https://www.gnu.org/licenses/lgpl.html#section4)

There is a massive reluctance in the QT community over this currently -- people want to distribute single-binary applications, and they are told to be careful about doing it.

The main security benefit of click-to-play plugin schemes is not to question the user about the security of an object, which is unknown in most cases anyway, but to prevent accidental drive-by loading and other annoying (and risky) usage. Clicking an overlay to run a plugin should be as natural as clicking on a video to begin playback.

At a minimum you'll need gstreamer1.0 and gst-plugins-ugly[1]. Perhaps gst-libav[2] would be an alternative to plugins-ugly.

OT: Check out http://mpv.io/. It's a forked mplayer2 with native support for libva:

  mpv --hwdec=vaapi --vo=vaapi

[1] http://gstreamer.freedesktop.org/documentation/plugins.html

[2] http://gstreamer.freedesktop.org/modules/gst-libav.html

I was under the impression that banal grammar corrections are frowned upon here on HN, because they do nothing to further the topic or encourage interesting discussion. It's one of the reasons why Reddit is so tedious.

Is the gender of said author supposed to be curious or worthy of attention? I'm not intending to be impolite, but this is the third time in several days that HN posters have brusquely corrected a gender pronoun in relation to a submission of nondescript importance.