I will try to ignore the shallow (but horrifying) issue of identifiers including spaces.
The real question to be asked here is what is wrong with the current portable assembler (C) ? C has occupied this niche for a long time and quite successfully - I believe all current mainstream kernels are written in C (or possibly a limited subset of C++).
If you want a 'portable assembler', a modern C compiler is in my opinion, a good choice:
- a solid specification: detailing the behaviour of operations, what is defined, implementation, or undefined behaviour.
- access to platform specific features through builtins and intrinsics
- ability to use inline asm if you really want to (or need to)
- easy integration with existing libraries
- minimal dependencies on a runtime library (pretty much none in freestanding implementations)
- most compliers give have ways to get good control of both what code is generated and structure layout.
The modern C ecosystem provides (mostly good) tools for:
Admittedly, most of these tools don't depend on the code being written in C, but I suspect any new language would take a while to get properly integrated. If you want to use a low level language, you really want to have access to these tools or equivalent.
A new language trying to compete in this space would have to offer something fairly substantial to get me to switch - and a strange syntax like zinc is not going to help. From the documentation at least, zinc seems to currently be missing: an equivalent to volatile; asm; anyway to access a CAS like instruction; 64bit types; floats; a way to interface to C code; clear documentation about behaviour in corner cases (what happens if you a left shift a 32bit value by 40?). The only thing seems to bring to the table to compensate is the ability to inherit structures
This submission prior to tptacek's (rather good) analysis was of little value. The original submitter gave absolutely no context to the diff.
I don't think we can depend on tptacek always being on hand.
This bug itself is not novel and something any programmer (if they are being honest) will admit to doing themselves.
The really interesting part of this story is not technical at all (and not evident from the posted patch) - why did the openbsd team not feel it necessary to release a security advisory for this bug. That decision may tarnish their reputation more than any wild conspiracy claims.
I presume you are attempting to imply that this one of the 'leet' FBI backdoors that the Perry email discussed. It would help if you actually said why you thought this patch was interesting when submitting it to HN.
I hope we are not going to get a rash of inarticulate HN submissions for every minor patch to openbsd which may have security implications.
I doubt this is in anyway related to the recent drama.
The initial bad patch which broke things looks like v1.63 of the file. This was committed in 2001 by angelos.
Note:
- angelos has a greek email address (for what it is worth)
- 1.63 was committed in 2001; the allegations of backdoors seem to be from 2000 and 1999
- it appears to break things for all non-ipsec aware nics. This seems to broad an error for an intentional backdoor
It also looks like the code didn't make it to a release branch before being fixed - so if it was an attempted backdoor, it was not successful.
Disclaimer: I have no experience with BSD kernel code nor with IPSEC.
Edit: I initially thought that angelos also commited the fix as well. I think I need to get my eyes tested
bcrypt is open source and ported to a range of operating systems. I cannot imagine getting it up and running on any system would be too difficult. It would probably be wiser to to spend the time to get bcrypt (or another standard scheme) working rather than coming up with some custom scheme which probably hasn't had the same level of thought put into it.
The real question to be asked here is what is wrong with the current portable assembler (C) ? C has occupied this niche for a long time and quite successfully - I believe all current mainstream kernels are written in C (or possibly a limited subset of C++).
If you want a 'portable assembler', a modern C compiler is in my opinion, a good choice:
The modern C ecosystem provides (mostly good) tools for:
Admittedly, most of these tools don't depend on the code being written in C, but I suspect any new language would take a while to get properly integrated. If you want to use a low level language, you really want to have access to these tools or equivalent.
A new language trying to compete in this space would have to offer something fairly substantial to get me to switch - and a strange syntax like zinc is not going to help. From the documentation at least, zinc seems to currently be missing: an equivalent to volatile; asm; anyway to access a CAS like instruction; 64bit types; floats; a way to interface to C code; clear documentation about behaviour in corner cases (what happens if you a left shift a 32bit value by 40?). The only thing seems to bring to the table to compensate is the ability to inherit structures