pb2au

The DNS solution has the benefit of working regardless of how the session is initiated.

But only for domains. Whereas the browser handling could say that the trusted-web-server on (common name) told me that X is a valid fingerprint for the sshd running on this same (common name). That sshd that runs on that port is customized and might create, like you mentioned earlier, a dynamically-created remote environment for the user.

If there were many web-servers/dynamic-sshd instances on a single domain, all the fingerprints would need to be added to the DNS. Granted, a unique use-case.. but the flexibility of browser handling would be nice.

The (common name) matching would be necessary as a same-origin policy.

edit: Basically, since the browser can understand the rest of the HTML/HTTP on the trusted page along with the ssh://name?fingerprint link, I think it makes sense to leverage it when wanting to open a connection to the same name, rather requiring the name to be a domain name and using DNS to get those values. For ssh:// links that aren't the same (common name) you wouldn't be able to use fingerprints (similarly to how you wouldn't be able to use fingerprints to the DNS entry for them).

On second thought, the port wouldn't matter, just the common name, since you've got a cert for it.

but that they can't afford a $10 domain name

The reason they would spend the money on the ownership of the IP and cert isn't because they can't afford the domain name. It's generally done for "mission critical" reasons because it takes out a class of weaknesses. DNS hijacking, DNS servers failing, DNS blocking by governments, etc. It could even be for vanity reasons, they may self sign, or w/e. It doesn't really matter, because the chance that these servers are going to be serving HTML to your standard web browser is pretty slim.

But I still think it'd be weird for DNS to be used here.

Using DNS for this:

  https://1.1.1.1 -> ssh://1.1.1.1:443 -> cannot connect (or require manual override)
  https://example.org -> ssh://example.org:443 -> check fingerprint in DNS w/ DNSSEC -> connected

  https://1.1.1.1 -> ssh://1.1.1.1:443 -> check fingerprint in trusted HTML/HTTP -> connected
  https://example.org -> ssh://example.org:443 -> check fingerprint in trusted HTML/HTTP -> connected

Anyways, thanks for the follow up post, I think I see your POV and agree with you that the DNS method would require much less work in order to get it work, given the current implementation.

explain a real world scenario where you have a web server with a valid certificate but you don't have a DNS entry for the server?

For example, if the certificate is assigned to an IP address. Not extremely common, but some people use it. [1]

You're inventing ridiculous scenarios to justify a nonsense concept of integrating html, browsers and ssh.

I stated (twice) that I think having the browser act as an SSH client is a silly idea. Not sure how I'm interpreted otherwise.

Both of my posts only point out that your intended correction (to just use DNS) wouldn't work for all cases, while the original post would work fine for authentication as far as I can tell. And that there are no inherent security concerns using in-band fingerprints, as opposed to looking them up via DNS w/ DNSSEC, if you already trust the integrity of the server response.

You keep replying along the lines of "well it's a bad idea to do SSH in the browser anyways", and I've already agreed with you there, because you're correct.

[1] https://support.globalsign.com/customer/portal/articles/1216...

Sorry, I re-worded "solution" to the lighter "suggestion" after posting, and I agree that there is likely a more fool-proof architecture (e.g. one not vulnerable to XSS; even HTTP headers would be an improvement, I suppose).

The idea (as I understand) is that you trust the data that you've received from the server, and the server knows the public key of the sshd that it wants you to use for login, so it provides the fingerprint for that public key.

I agree that browsers shouldn't use SSH; it's overkill. But in the example (for humor), the browser does worry about SSH keys, because it is an SSH client. "Just use DNS with DNSSEC" won't work for direct IP addresses. Using client side certs is unnecessary, as the trusted web server is only telling you the conditions under which it is okay to authenticate. If you already trust the integrity of the data, it isn't more dangerous (from a security standpoint) than when you you get a page over HTTPS that tells you to POST to /login.

Besides the fact that we both think that the browser as an SSH client is silly, I don't think the suggestion of providing the fingerprint in DNS with DNSSEC is any more secure than a trusted web server providing it, but it would not work for direct IPs.

The parent's suggestion would work if accessing the server by IP address directly, rather than DNS lookup. Assuming that the integrity of the data has been verified by the transport, I don't see the downside to the server providing the fingerprint in the HTML.

Does your university actually block all other wireless networks near / on campus? This is prohibited by the FCC.

At my university, the wireless APs would scan for others and try to detect if they were on-network using a student's auth. They'd tell the student to remove the AP if they wanted to continue to have access to the school network. Wireless, off-network hotspots were allowed, provided they weren't impersonating the school network.

glibc 2.18 and greater were already patched, but it wasn't recognized as an RCE vulnerability at the time. See the first bullet under the "Mitigating factors" section in the link.

You can check your libc version with:

  ldd --version

It isn't the format string syntax that is the problem that they're trying to solve. I see this as being an iterative, backwards-incompatible improvement on the existing format convention. Changes in convention don't have to be all or nothing.

Hi again,

No. Copyright can be used to protect moral rights, [...]. In places where moral rights are in the law, they are not subject to copyright at all.

It doesn't matter. [...] Whether there are legal systems without copyright is irrelevant to this.

Sorry, I think we are just disagreeing on the definition of copyright here. I use the definition that moral rights are under the umbrella of copyright. For example, Wikipedia defines moral rights as "rights of creators of copyrighted works generally recognized in civil law jurisdictions and, to a lesser extent, in some common law jurisdictions" [1]. You could have moral rights without property rights, but not without copyright. And, again, I don't think there are any countries that actually have moral rights without property rights, which I do consider important for discussing the claim that respecting property rights is unnecessary.

What licenses would those be, if there's no copyright? You're still thinking in a matter formatted by the current US law.

You claimed that moral rights were important, but property rights were not (or maybe I've misunderstood). The MIT license is generally protective of moral rights (attribution), while the GPL protects both moral rights and property rights (attribution and "you may use the code under these conditions"). By saying moral rights are only important, it's the same as saying any GPL code could be re-licensed under the MIT license. So the situation I mentioned was using previously GPLed code in a closed-source binary, because the company does not respect the copyright (property rights) of the author, even if they keep the attribution (moral rights).

The original topic discussed was: "If you believe in open source, then you need to be respectful of copyright law. It is the foundation for open source licensing."

Which I think is made clear by the example. By nobody respecting property rights, closed-source binaries could use GPLed code, with the stipulation that the binaries themselves can be reverse engineered legally. It isn't a good trade-off. The binaries are no longer proprietary (i.e. have ownership rights), but are still very hard to use.

As I said earlier, a law could be promulgated that granted the author the right only to prevent others from using code written by him in proprietary binaries - while not granting him/her the right to restrict any other copying.

This itself sounds like a copyright law that grants certain property rights to the author. Earlier you mentioned abolishing "economic rights" and stated "essentially, the attribution right is the goal". But, as it turns out, some property rights are liked ("I made this, so I want to release it under X condition!"), so if you expect others to respect your terms, it is important to respect theirs, imo.

That's why I consider respecting copyright to be important for open source -- to me it seems like the "golden rule" of authoring code; if I want my GPL code to be protected, I should respect the license of their proprietary code.

I don't have any more time for the discussion, but I think I've expressed my view the best I can.

[1] http://en.wikipedia.org/wiki/Moral_rights

For example, here in civil law countries, there's commonly no "copyright" as such; there's Moral Rights (which protect stuff like attribution) and Economic Rights. Therefore, there's no implication that abolishing Economic Rights like restricting others from copying must also abolish attribution rights

You're correct that moral and property rights are distinct in many civil law countries, but both are under the umbrella of copyright and, as far as I know, there are no countries that enforce moral rights but not property rights. I'm aware that there are countries that do the reverse: acknowledge property rights but not moral rights. Which countries' legal systems do you have in mind?

And that applies to the GPL as well - I can defend the right to prevent others from using your code in closed binaries, without having to defend the wider right of prevent any copying at all. (Though in my particular case, I wouldn't mind losing copyleft if copyright was to be abolished)

According to the idea that we should not respect property rights (and, like you say, only respect attribution / moral rights), this would allow the company to re-license GPL code under an MIT license, then use the newly MIT-licensed code in ways that were unintended according to the original author (i.e. inclusion in non-GPLed code). Like you mention, this could be in the form of closed-source binaries, which of course could be reverse engineered legally, because of no property rights, but, really, this system seems terrible to me.

While I love open source software and acknowledge that copyright can be abused, I can't see the benefit of a system that permits you to take the work of someone else, ignoring their conditions, then modify and re-distribute it as if it were under something similar to an MIT license -- respecting only attribution.

Also in a previous comment by the author, before the DMCA:

I also believe that it's not in Trello Inc. interest to try to censure us because of the Streisand effect, and it would be overly complex (I live in France, Yaşar lives in Turkey, we don't have a common company or an organization, and in fact we never met each other in the real life), and even if they stop us, and because the code is distributed under the MIT license some other will take the relay (remember PopCornTime anyone?).

That, combined the author posting it to on HN several hours after getting the DMCA, makes it clear that the author does not care about blatantly ripping off and redistributing others' work. Regardless of whatever their proposed solution would be for correcting the infringement, I doubt this project will ever be safe to use under assumption of an open source license.

It depends on your meaning behind "free distribution", but arguably most open source licenses don't exist to provide that specifically -- they exist to permit it while abiding by the other conditions on the license.

For example, if you don't respect copyright law, you wouldn't be able to argue that a corporation taking GPLed code and incorporating it into a proprietary product is immoral nor taking BSD licensed code and removing a link back to the original author is immoral.

The argument that I recall for Chrome not having an optional master password was that it was often less secure than using the system's encrypted data store for their account, if available.

Requiring a master password to decrypt the network passwords is a perfectly fine idea if you want to maintain portability and reduce the chance that your network passwords are accidentally exposed. An attacker has to both have the password file and either figure out the master password or have code execution privileges on the user's account to gain the network passwords. This is more secure than trying to ensure the password file doesn't get "misplaced" (e.g. on an unencrypted drive, in unencrypted backups, unintentionally through a fileserver, etc).

Reddit does intend to have the /r/blog posts on the front page, but they don't necessarily need to rig the votes.

As mentioned in the article, the algorithm for selecting which posts appear on the homepage seems to allocate slots for each subreddit. If one subreddit has more people voting than another subreddit, they can both appear alongside each other, rather than the larger one always filling the homepage.

Since the only posts made to /r/blog are infrequent, they will always get the slot for the subreddit and will likely always appear on the front page or second page even with few votes. Then, because they are visible to many users, they can attract more votes.

The LGPL references the terms of the GPL in the context of the library released under the license. For both versions 2 and 3 of the GPL, it states that build instructions must be made available [1].

[1] https://www.gnu.org/licenses/quick-guide-gplv3.html#less-sou...

In addition, the overzealous, erratic clicking originating from an obscure extension could make it pretty easy to detect these users.

The only result would be filtering out their traffic from counting towards any PPC ads and more accurate tracking of the individual users. There isn't an upside to running this extension.

Thanks for the second example. It's a more clear use-case than the mischievous do_damage() function I had in mind.

I think intent would definitely play a role in establishing liability for damaged equipment (i.e. the user misusing the device versus the company tampering with the user's equipment).

A NAS box "only compatible with brand X drives" is nowhere near a NAS box that intentionally bricks non-brand X drives when attached.

As a side note, are there any known cases where a vendor has released open source code that intentionally bricks a device? I'd be surprised if they were not found legally liable if the intent was spelled out so clearly.

While it may not be much of a stretch, it still hampers his point. If the goal is to convince an audience of people who are evaluating the technical aspects of systemd that there is a viable alternative to using it, the continued reference to the less-than-polite demeanor of many detractors isn't helping to further his point.

As well, many (most?) people associate "trolling" with "intentional griefing" and not "willful ignorance". I believe that many of the people arguing against systemd are either ill-informed or only considering their own use-cases, but I don't think it is appropriate to generalize them as trolls if their goal is something other than "to make people angry".

Pretty cool hack, but not one I'd hope to run across in any real code. Between the nondescript function header and the inability to differentiate between an unset argument and a zero-set one, this macro would too quickly become a headache.

I disagree.

When you use a password manager and separate passwords for each website, you're effectively eliminating an entire class of potential attacks, because any leaks from the website will not affect your accounts elsewhere (especially bad for accounts with privileges such as your email or bank accounts).

In exchange, you use a password or key to locally decrypt the rest of your passwords. This means for someone to have access to your password store they have to (1) find a vulnerability in the password manager store file or (2) obtain access to your machine. Comparing these, (1) is much less likely than getting a password list from a server with more attack surfaces, and (2) would also leak your passwords even without a password manager.

It may seem strange to think of all your passwords as being protected by a single password, but the key concept is that you aren't sending that password across the wire, but do regularly send the others. If your local machine is insecure, it doesn't really matter whether or not you are using a password manager.

Obviously, it would be even more secure to have different passwords for each website and be able to remember all of them, but it's not a very reliable method of storage and puts too large a burden on the user.

The great-grandparent suggested:

  echo "Testing status update" >> /facebook/me/posts

The current model seems similar to the REST interpretation of CRUD, where > equates to 'create' and >> to 'update', and creating a resource is done at the collection URL. Nothing wrong with this, but it seems slightly unintuitive to me.

My suggested mapping would be:

  >/facebook/me/posts - Unsupported (or delete all posts, and make a new one)

  >>/facebook/me/posts - Add a new facebook post

  >/facebook/me/posts/long_numeric_id - Update post (truncate)

  >>/facebook/me/posts/long_numeric_id - Update post (append)

Also, nice work! The project reminds me of Plan 9's /net.

It took me a couple seconds to figure out there was content below the auto-resizing header image. I tried to click on both the "Documentation is easy" and "FLATDOC" text to see if either were links to the content before realizing there was a scroll bar.

I'd suggest not having such a large image, or at least resize it to only expand to a portion of the screen, to prevent confusion.