3 ms·

The linked GitHub issue mentions this: The new platform is a different system and doesn't run Java so it's not using the old code that was open. They found no r

The linked GitHub issue mentions this: The new platform is a different system and doesn't run Java so it's not using the old code that was open. They found no reason to publish the new code as it doesn't help anyone since it's integrated into the rest of their platform. And it sounds like you can't update the code. So you don't have a way of verifying what the actual device runs. So people complaining about trust here are somewhat misguided when they say they don't want to trust Yubi. Open sourcing would only help find non malicious bugs. Since it sounds non modular there's possibly all sorts of stuff mixed in making it hard to audit so they decided it wasn't worth it. Dunno if that's right but that's what it sounds like.

Freak_NL 10y ago
Strange. Yubico's dainnilsson is usually quite forthcoming with responses to questions, but his final response in that GitHub thread worries me (he seems harrowed). I am genuinely curious what reason there could be not to open-source the code. I am not expecting any trade secrets in there; any competitor's biggest challenge by far is getting the hardware right and getting an assembly line going. On the other hand, keeping the code closed does garner a lot of distrust.
kerkeslager 10y ago
> Open sourcing would only help find non malicious bugs. 1. This isn't exactly true; Yubico as a whole might be trustworthy but that doesn't mean individuals within the company can't slip in something that looks benign but breaks security, and slips past the other developers. Such vulnerabilities are documented even in open-source code[1]. 2. Even non-malicious bugs can have security implications. [1] http://www.securityfocus.com/news/7388 http://www.securityfocus.com/news/7388
zobzu 10y ago
it is true that you cannot update the code, though the neo before the yubikey 4 was still running java applets and they had already disabled the possibility to update the code by requiring the yubico private company key (they're still using java applets). the original neo let you decide of the key/write to the neo, etc. Thus they did not "disable it because of hardware", it is a choice of their, which they had already made for a year or two anyway.
- MichaelGG 10y ago
  They say the new platform lacks Java and doesn't have an applet model. Or am I misunderstanding?

Freak_NL 10y ago

Strange. Yubico's dainnilsson is usually quite forthcoming with responses to questions, but his final response in that GitHub thread worries me (he seems harrowed). I am genuinely curious what reason there could be not to open-source the code. I am not expecting any trade secrets in there; any competitor's biggest challenge by far is getting the hardware right and getting an assembly line going. On the other hand, keeping the code closed does garner a lot of distrust.

kerkeslager 10y ago

> Open sourcing would only help find non malicious bugs. 1. This isn't exactly true; Yubico as a whole might be trustworthy but that doesn't mean individuals within the company can't slip in something that looks benign but breaks security, and slips past the other developers. Such vulnerabilities are documented even in open-source code[1]. 2. Even non-malicious bugs can have security implications. [1] http://www.securityfocus.com/news/7388 http://www.securityfocus.com/news/7388

zobzu 10y ago

it is true that you cannot update the code, though the neo before the yubikey 4 was still running java applets and they had already disabled the possibility to update the code by requiring the yubico private company key (they're still using java applets). the original neo let you decide of the key/write to the neo, etc. Thus they did not "disable it because of hardware", it is a choice of their, which they had already made for a year or two anyway.

MichaelGG 10y ago
They say the new platform lacks Java and doesn't have an applet model. Or am I misunderstanding?