> Why aren't you using this logic to argue that they should use Delphi or TurboPascal because Anders Hejlsberg created those?
as you know full well, Delphi and Turbo Pascal don't have strong library ecosystems, don't have good support for non-Windows platforms, and don't have a large developer base to hire from, among other reasons. if Hejlsberg was asked why Delphi or Turbo Pascal weren't used, he might give one or more of those reasons. the question is why he didn't use C#, for which those reasons don't apply.
Allegedly, one major reason is that Apple has been successfully pressured by Greenpeace to remove PVC from their cables, causing them to be more brittle and fail sooner. https://fee.org/articles/this-is-the-real-reason-your-iphone... is one source, but Apple and Greenpeace themselves tout this "achievement". It seems to me to be just like replacing nuclear power with coal and natural gas power: another casualty of ideological extremism at the expense of the actual environment.
it was in fact created using state-of-the-art windows gui frameworks. in 1995. and then never updated. is it really an improvement to have a win10 settings app that is all unified... except for most of the advanced settings and half of the basic settings which are only available in the control panel?
Location: Toronto, Canada
Remote: OK
Willing to relocate: Within Canada, US, EU
Technologies: Python, C, Linux, networking
Résumé/CV: https://alxu.ca/resume/
Email: see resume
> The SLoC of IPSec kernel code are comparable to the SLoC for WireGuard kernel code.
I haven't checked whether this is true, but even if it is, that's a damning indictment of IPsec, because on Linux, the entire connection establishment is in userspace, and the kernel only handles per-packet encryption and authentication. WireGuard has the entire negotiation sequence, authentication, routing, timeouts, rekeying, etc in the kernel. With IPsec, you need to have a userspace daemon to manage all of that, with significantly more LoC than the bare per-packet essentials. With WireGuard, you just load the keys into the kernel and you're done. I bet that you're also counting Zinc against WireGuard, but not counting the entire crypto API against IPsec (which, unlike with WireGuard, you might end up actually using).
I suspect that it's not actually true though in the first place, once you add in all of the other stuff like iptables -m policy that only exists to support IPsec.
the "none" cipher isn't even that bad... if you do a packet capture, you can clearly see that the data is unencrypted. the worst part about IPsec is that there are many modes which look secure, but actually aren't secure at all. examples: encrypted but unauthenticated packets, encrypted but unauthenticated channel negotiation, encrypted by default but downgradable cipher negotiation...
my point is that it would appear that "Anyconnect Secure Mobility Client" has a shitton of vulnerabilities. sure, wireguard may have some vulnerabilities, but you don't need a formal audit to tell the difference between "this might have some issues" and "holy fuck this is a fucking dumpster fire". you need an audit to tell if "this might have some issues" is "this has some issues" or "this is actually pretty good". in particular, "Anyconnect Secure Mobility Client" appears to have a significant number of local privilege escalation exploits, some several dozen since 2011. that doesn't necessarily mean that the protocol is shit, but it probably does. it probably means that no serious security professionals have examined it, and the vulnerabilities that have been found are just the easiest ones that can be found with a scanner.
but even ignoring all of that, wireguard has significantly better security guarantees. https://www.wireguard.com/formal-verification/ claims that "WireGuard has undergone all sorts of formal verification, covering aspects of the cryptography, protocol, and implementation." with references to several formal proofs of the protocol.
furthermore, wireguard has actually received a CVE: CVE-2019-14899, which was posted here only a few weeks ago. it's not wireguard-specific though, it's a general problem with VPN setup on general-purpose operating systems.
as you know full well, Delphi and Turbo Pascal don't have strong library ecosystems, don't have good support for non-Windows platforms, and don't have a large developer base to hire from, among other reasons. if Hejlsberg was asked why Delphi or Turbo Pascal weren't used, he might give one or more of those reasons. the question is why he didn't use C#, for which those reasons don't apply.