[HN Gopher] OpenSSL will release a high-severity issue fix on 25th
___________________________________________________________________
OpenSSL will release a high-severity issue fix on 25th
Author : yread
Score : 257 points
Date : 2021-03-22 20:21 UTC (2 hours ago)
(HTM) web link (mta.openssl.org)
(TXT) w3m dump (mta.openssl.org)
| yholio wrote:
| Can't believe that, in God's year 2021, 3rd millennia, Earth,
| we're still using security libraries written in what is
| essentially a portable assembly language, doing silly things like
| pointer arithmetic, manually allocating memory, and other
| chainsaw juggling feats.
|
| I swear some day we'll look back to this period with
| bewilderment: son, in those days people used to smoke carcinogens
| for their taste, drive their own cars and treat mental disorders
| with an ice pick in the prefrontal cortex. Trully mad men would
| even implement X.509 in unsafe languages.
| throwaway823882 wrote:
| 1. There is no such thing as a safe or unsafe language. Safety
| is relative and impossible to guarantee.
|
| 2. Inline assembly is one of the best ways to create
| implementations of crypto libraries. That's why the best
| cryptographers in the world use it.
|
| 3. It's all machine code under the covers. Whether one
| developer poorly juggles chainsaws or your high-level language
| poorly juggles chainsaws is not a question of better or worse,
| but taste.
|
| 4. It's X.509. It sucks in every language.
|
| 5. Just because it's in C doesn't mean it sucks. There are
| alternatives that intentionally avoid sucky design.
| (https://nacl.cr.yp.to/internals.html)
| maerF0x0 wrote:
| Go seems to have it's own SSL lib
|
| https://groups.google.com/g/golang-nuts/c/0za-R3wVaeQ
| covid_gopher wrote:
| that's nice to hear, it is only lacking a proper programming
| language then
| elwell wrote:
| What 'til you see a Solidity [0] smart contract...
|
| [0] - JS -\\_(tsu)_/-
| vntok wrote:
| Nonsense. Solidity is a statically-typed programming
| language.
| jamescun wrote:
| We don't know what the vulnerability is yet. Sure it could be a
| buffer overflow, readily possible in a language like C, or
| could be a bug in the crypto/implementation itself, no memory
| safe language will save you there.
| tptacek wrote:
| It would be good to know if this vulnerability was related to
| memory safety before pinning it on memory safety. You can get
| cryptography just as wrong in Rust or Go.
| dochtman wrote:
| No argument from me that you can easily go wrong in any
| language, but I would argue that Rust has features other than
| memory safety that can also assist in building more
| reliable/secure software.
| wglb wrote:
| Such as?
| bluejekyll wrote:
| The Rust type system can define parts of the state
| machine that can help guarantee certain states are true
| at compile time.
|
| This is very helpful for not using cryptography libraries
| incorrectly, or not accidentally using the wrong data at
| different points of implementing functions.
|
| Generally more applicable to higher level use cases, the
| _ring_ [1] library is a great example of how the
| algorithms (same impls as OpenSSL) are exposed to end
| users.
|
| [1]: https://github.com/briansmith/ring
| dochtman wrote:
| Match statement exhaustiveness checking is one example,
| especially combined with the pervasiveness of enums
| (instead of constants).
| junon wrote:
| Any respectable C compiler does this.
| sshine wrote:
| Like the one OpenSSL is being compiled with?
| SubjectToChange wrote:
| What C compiler has pattern matching and ADTs?
| junon wrote:
| Every C compiler these days will warn about unchecked
| enums in switch statements. This is, effectively, what
| the comment was saying.
|
| Pattern matching has nothing to do with security or
| program safety.
| hn8788 wrote:
| From what I remember, you can't write a secure cryptography
| library in pure Rust because it has no guarantees that would
| stop timing-based vulnerabilities.
| [deleted]
| SAI_Peregrinus wrote:
| Neither does C. Timing is not considered "observable
| behavior" in the C standard, so compilers don't have to
| preserve it.
| creata wrote:
| It looks like at least libsodium implements constant-time
| array comparison in C.
|
| https://github.com/jedisct1/libsodium/blob/ae4add868124a3
| 2d4...
| kroeckx wrote:
| We've had code in OpenSSL written in C that was constant
| time until a newer version of both gcc and clang
| recognized (mask & a | ~mask & b) as a conditional assign
| and could do things like turn it into a branch.
| Arnavion wrote:
| And indeed the XOR method is also how it's implemented in
| Rust.
| dfox wrote:
| Which is prime example as to how C does not consider
| timing to be observable behavior. What the code does is
| that it tries to specify the operation in sufficiently
| complex way that makes compiler give up on any
| optimizations.
| Denvercoder9 wrote:
| There's nothing that guarantees that's constant-time.
| It's just written in a way that's likely to be constant-
| time, and observed to be constant-time with current
| compilers, but there's no reason why a specification-
| compliant compiler couldn't make it variable-time
| tomorrow.
|
| You can do exactly the same in Rust. Rust isn't any help
| there, but it doesn't obstruct you either.
| bluejekyll wrote:
| While this is a true statement, it doesn't feel accurate.
| Rust's type system offers a significant number of features
| over that of C beyond just memory safety. These come in the
| form of safe unions (with Rust enums), Generics with
| ZeroSizedTypes for ensuring states of computation happen in
| the proper order, safe destructuring of values such that the
| wrong field isn't referenced.
|
| Point being, a Rust library that incorporates these type of
| safety measures can help significantly reduce programming
| errors beyond just memory safety issues.
| spijdar wrote:
| Memory errors and the sort of logic errors you described
| are one source of program errors, but I think the more
| devious ones are much higher level. There's a general taboo
| surrounding rolling your own crypto for a reason -- there
| are too many high level footguns that have nothing to do
| with raw program logic that can make a crypto system
| insecure or vulnerable to some kind of exploit, not
| necessarily relating to the code at all! Problems in
| randomness, distribution, other things beyond my pay grade.
|
| Rust being higher level will prevent errors, yes, but
| crypto is hard on a whole other level. It's worth "waiting
| and seeing" what sort of vuln this is before jumping all in
| on the rust train this time ;-)
| dvdkhlng wrote:
| I just started wondering, if things were any better if security
| libraries were written in higher level languages, depending on
| on a _huge_ run-time support system that is written in what is
| essentially a portable assembly language, doing silly things
| like pointer arithmetic, manually allocating memory and so
| on... :)
| oolonthegreat wrote:
| "what is essentially a portable assembly language" amen to that
| :)
| ancarda wrote:
| >in those days people used to smoke carcinogens for their
| taste, drive their own cars and treat mental disorders with an
| ice pick in the prefrontal cortex
|
| Do you imagine a future where nobody is able to drive cars? Not
| even for fun?
|
| I want all serious software that's written in C to be replaced
| with something like Rust, but I write C for fun. It's fun to do
| dangerous things. It's just bad to have danger as the modus
| operandi.
| tshaddox wrote:
| I don't think many people begrudge people who ride horses for
| fun or write security software in assembly for fun.
| airhead969 wrote:
| I like doing dangerous things for fun too. (See also: my 50
| mph scooter.)
|
| I think we should mitigate risk in serious software in many
| holistic ways such as formal verification, fuzzing, anomaly
| detection, good/defensive coding standards, code reviews, and
| so forth. Such can be accomplished in C, but it maybe easier
| in languages such as Rust. The advantage of C is ubiquitous
| portability, which is necessary for widely-used libraries.
| ancarda wrote:
| You're right there's a lot of tools out there to help with
| writing secure code in C. I suppose I feel safer knowing
| Rust enforces some memory safey, but that isn't guaranteed
| either -- you could just use unsafe{} blocks everywhere.
| kroeckx wrote:
| As one of the OpenSSL maintainers, I would like to move away
| from C and probably to rust. But the problem is that C is the
| most portable language, and rust's platform support just isn't
| close enough.
| usefulcat wrote:
| > Can't believe that, in God's year 2021, 3rd millennia, Earth,
| we're still using security libraries written in what is
| essentially a portable assembly language, doing silly things
| like pointer arithmetic, manually allocating memory, and other
| chainsaw juggling feats.
|
| I suppose the flip side of this view is just how easy it is to
| underestimate what a truly enormous amount of work it would
| take to completely reimplement all these 'chainsaw juggling
| feats' that are used all over the place, day in and day out.
| kaliszad wrote:
| This is why we need simple systems above all. That also means
| having protocols and in general technologies that are as
| simple as possible while of course being useful. Especially
| in basic infrastructure, the cost of every new feature should
| be evaluated as a priority. The cost of bugs also should be
| considered. Libraries the world basically depends on should
| be an example how to do these things right.
|
| The reality is, we see constant stream of patches to bugs we
| know for certain are security related to basically any
| software we use all the time. Am I the only one to think
| every such patch should be delivered with sweat running down
| our backs asking ourself how this could have happened at all
| in such critical software? Instead we introduce regular patch
| days, responsible disclosure and other protocols that don't
| solve the issue itself, that basically our software stacks
| are not maintainable at all if we are being frank.
|
| In my opinion, we will have no dependable security until a
| handful of skilled engineers are together able to understand
| the systems we use fully. One can understand the more low
| level stuff, the other maybe the middle etc. with some
| reasonable overlaps so the security of the stack as a whole
| can be reasonable evaluated and maintained. This is currently
| just not realistic with any team size, when even the firmware
| of our CPUs has to be patched constantly. I mean, when you
| launch e.g. Gmail, who really understands everything from the
| JavaScript until basically the lowest level firmware in a
| clients computer? I guess, nobody and not even any team on
| the planet comes even close to grasping the full depth and
| breadth of the stack. Therefore the security and other
| quality related aspects cannot be evaluated without broad
| oversimplification that really doesn't add anything to the
| discussion.
|
| If we don't wont to really change our ways, we should at
| least be frank and say that the software we actually use will
| never be fully secure, correct or dependable. Just as much as
| bridges fall, dams break and fallen power-lines create
| widespread fires we are just not able to handle this stuff
| reliably. If that is not scary enough, just imagine the
| software and other infrastructure handling security at
| nuclear power plants, processing centres and weapons. (And
| no, engineers are not the only ones having no clue. Doctors,
| medics etc. don't have a clue either as we see with the
| pandemic, still unsolved diseases everywhere, even stuff like
| hearing loss from stress is not understood well.)
| rafaelturk wrote:
| so..`yholio` Rants asside what is your valuable contribution to
| the library or creating a new impecable one? I'm acutally glad
| we have such powerfull library available for free and using
| open source code so we can audit it and find bugs
| colejohnson66 wrote:
| > open source code so we can audit it and find bugs
|
| Open source didn't stop Heartbleed
| zokier wrote:
| But it did, eventually.
| eurasiantiger wrote:
| All bleeds stop eventually.
| alerighi wrote:
| The problem is not the language! If C is not sufficiently safe
| for you, you shouldn't take planes, or drive cars, or rely on
| medical devices, because the software of all these critical
| embedded system is written in C.
|
| The problem is on how you write the software. There are
| projects that have strict code standard, such as MISRA C or
| even stricter ones. The problem is that such a critical
| software (well, relatively critical, because if there is a bug
| in a security library nobody dies in the end) is not written to
| that standards.
| anonymousiam wrote:
| Static analysis tools should also be a normal part of the
| development process regardless of the language being used.
| Unfortunately, the good tools cost money and that discourages
| developers (and managers) from using them.
| pas wrote:
| > if there is a bug in a security library nobody dies in the
| end
|
| The University Hospital Dusseldorf (UKD) in Germany suffered
| a ransomware attack on September 10, 2020. The attackers
| exploited a vulnerability in the Citrix ADC that had been
| known since January but the hospital, unfortunately, had not
| got around to implementing the fix.
|
| Unfortunately, one patient with a life-threatening illness
| was diverted to a distant hospital after UKD was deregistered
| as an emergency care facility. The additional hour's travel
| may have been the cause of the patient's death. On September
| 18, 2020, German prosecutors launched an official negligent
| homicide investigation which, if confirmed, would make the
| patient's death the first known case of death by hacking.
|
| :|
| vntok wrote:
| Is Citrix ADC a security library?
| formerly_proven wrote:
| It's a network security appliance - undoubtedly contains
| multiple security libraries.
| m00dy wrote:
| yes, the problem is not the language. The problem is that
| OpenSSL has just became so important that It shouldn't not
| rely on C language any more. We have so much better tools
| now.
| larodi wrote:
| Planes actually have major portions of the software written
| in non-C languages such as ADA - see https://www.manufacturin
| g.net/aerospace/news/21175187/airbus...
|
| And are very proud of it. Medical equipment is not all
| implemented in embedded C systems.
|
| And since modern embedded systems can easily run python or
| embedded JS versions, well, perhaps certain critical libs can
| actually get implemented in something that does not deal with
| memory... and the 5-10% penalty in performance is not going
| to be something anyone really notes.
| jk7tarYZAQNpTQa wrote:
| > The problem is not the language!
|
| It is. A language that lets you write unsafe code is an
| unsafe language.
|
| > If C is not sufficiently safe for you, you shouldn't take
| planes, or drive cars, or rely on medical devices, because
| the software of all these critical embedded system is written
| in C.
|
| Citation needed. I would expect those programs to be written
| on a language with very strict types and no pointer
| arithmetic bullshit.
|
| And even if some of these software pieces are written in C,
| (a) that's their bad, and (b) it may be suitable for their
| scenarios. A program that reads and parsers unlimited amounts
| of user input, supports an ever growing list of complex (and
| often not improperly defined) protocols, and is often
| edited/expanded/updates, is definitely not such a scenario
| for C.
|
| > The problem is on how you write the software. There are
| projects that have strict code standard, such as MISRA C or
| even stricter ones.
|
| Again, the problem is the language, not how you use it. If
| the security of a piece depends on how it is manipulated, it
| is by default insecure. A secure language shouldn't let users
| make mistakes (or at least avoid them to a high degree). And
| a library that is the backbone of the confidentiality and
| privacy of millions of people (and billions of dollars in
| businesses) should be written on a secure language.
| cameldrv wrote:
| Even safety critical software can run reliably for the range
| of inputs that it's likely to ever see, but contain security
| holes.
|
| For something like OpenSSL, it must produce a correct output
| for every single possible input. Even safety critical
| software may extremely rarely fail in unusual conditions. For
| security sensitive software though, all it takes is a single
| possible input that will trigger a bug, because the attacker
| is not a random process.
|
| Writing secure software in C is extremely difficult.
| diegocg wrote:
| That's like having a field full of mines and then arguing
| that the field is not dangerous because you have a map of the
| mines. If you have to develop strict coding standards not
| just to write reliable code but to avoid the pitfalls of a
| language that others don't have, then that proves that the
| language sucks.
|
| We have languages that can provide certain levels of MISRA
| safety even if you are a novice programmer.Blaming the users
| for not following the correct guidelines (that barely anyone
| follows except for the people paid to follow them) completely
| misses the point.
| airhead969 wrote:
| It's swiss-army chainsaw juggling with a kitchen-sink of
| unnecessary features, bloat, and poor coding hygiene.
|
| C isn't the problem per se, it's the lack of quality, formal
| rigor, and testing that these slap-dash developers foist on the
| world. It's a steaming pile, and people wonder why it has
| security vulnerabilities over and over again. It's doing the
| same damn thing and expecting a different result: C maybe part
| of it, but its developers just aren't that great.
| rafaelturk wrote:
| Can't wait for your PR!
| ori_b wrote:
| https://www.libressl.org/
| airhead969 wrote:
| It's a fork of swiss-army chainsaw juggling with training
| wheels. It is a slowly-dying project because it's not
| keeping up and distros are dropping it. It's not a viable
| alternative.
| nightpool wrote:
| As mentioned down-thread, LibreSSL patched a use-after-
| free just last week.
| 29athrowaway wrote:
| How else do you expect that national security agencies do their
| job? :^)
| ashneo76 wrote:
| I am all for shared libraries. Update openssl and everything else
| gets the patch. With rust/go, now I have to wait for all the
| authors to release their fat binaries of the same dependencies
| edoceo wrote:
| There was a post here a few days ago by one of the Gentoo
| maintainers talking about how static builds are bad and this
| exact reason (security vulnerability that touches lots of
| things) was one mentioned.
| jonas21 wrote:
| Note that HIGH severity isn't the _highest_ severity (that 's
| CRITICAL) [1].
|
| The last high severity fix in OpenSSL was this past December.
|
| [1] https://www.openssl.org/policies/secpolicy.html
| 0x003 wrote:
| > HIGH Severity. This includes issues that are of a lower risk
| than critical, perhaps due to affecting less common
| configurations, or which are less likely to be exploitable.
| These issues will be kept private and will trigger a new
| release of all supported versions. We will attempt to keep the
| time these issues are private to a minimum; our aim would be no
| longer than a month where this is something under our control
|
| So something to make sure you update, but not a Heartbleed
| level concern
| hosteur wrote:
| What was the severity of heart bleed?
| richardwhiuk wrote:
| https://www.openssl.org/news/secadv/20140407.txt is the
| advisory, but this was back when OpenSSL wasn't as well
| maintained.
|
| It would have been CRITICAL.
| leonardinius wrote:
| It was CRITICAL and warranted new severity level added [1]
|
| [1] - https://www.openssl.org/blog/blog/2015/09/28/critical-
| securi...
| [deleted]
| janvidar wrote:
| Not sure if this is related, but LibreSSL released version 3.2.5
| with _one_ fix last week:
|
| * A TLS client using session resumption may cause a use-after-
| free.
| mjevans wrote:
| Why is this embargoed until a Thursday; isn't "patch Tuesday" the
| usual mantra? That's the downtime window where I work as a
| result.
| danielheath wrote:
| "Patch Tuesday" is a Microsoft policy afaik, not a global one.
| Aaargh20318 wrote:
| Sure, but still strange to release this on a Thursday
| afternoon. This means that everyone who depends on OpenSSL
| needs to rebuild and test and will have an update ready on
| Friday afternoon in the best case.
|
| Who wants to roll out any kind of update to their production
| systems on a Friday afternoon ? That's just asking for
| trouble.
| qbasic_forever wrote:
| On the other hand, this is a high severity issue in
| security critical code that has had huge exploits in the
| past (heartbleed). This is the kind of security patch a
| good ops team is expecting and ready to handle at a
| moment's notice. It's far less annoying to do a Friday
| afternoon update than deal with active exploits all
| weekend.
| mjevans wrote:
| Yes, but knowing others, particularly in other companies,
| expect downtime on Tuesdays as a result, wouldn't you also
| pick the day everyone expects that downtime?
| tedunangst wrote:
| I think you have mismanaged your expectations.
| sekh60 wrote:
| Patch Tuesday is a Windows thing generally.
| trinovantes wrote:
| For the average developer what do I need to do? I don't use
| OpenSSL directly but I'm pretty sure some parts of my tech stack
| use it as a dependency. Do I simply need to run `apt-get upgrade`
| on the 25th?
| qbasic_forever wrote:
| Watch the debian security mailing list for information about
| when their fix is available to others through apt:
| https://lists.debian.org/debian-security-announce/ In general
| you should be following this list if you're managing production
| services running debian or ubuntu.
| throw0101a wrote:
| > _Do I simply need to run `apt-get upgrade` on the 25th?_
|
| Mostly, but some details matter.
|
| Make sure that when you do the _upgrade_ , that you are
| fetching the fixed version. Check for the security announcement
| and see which version things get fixed in:
|
| * https://www.debian.org/security/
|
| Once the CVE is known, you can also see which versions are
| vulnerable and which are fixed:
|
| * https://security-tracker.debian.org/tracker/CVE-2020-1971
|
| You may have to restart some services. The _checkrestart_
| utility is handy to find these:
|
| * https://packages.debian.org/buster/debian-goodies
|
| * https://packages.debian.org/search?keywords=debian-goodies
| vbezhenar wrote:
| Restart your services or better reboot your server to be sure.
| tedunangst wrote:
| Maintain a constant state of suspicious alertness until March
| 25th.
| dang wrote:
| This is a pretty low-information post and the discussion is
| therefore pretty generic. In such cases it's better to wait until
| the thing actually comes out, and with it enough information to
| support a specific discussion.
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
| bluejekyll wrote:
| dang, do you think the fact that this is announcing a date in
| the future to look out for potentially an exploitable issue and
| folks may want to discuss ways to mitigate that?
|
| granted, much of the discussion is not about that at this
| point, though there is a bit:
| https://news.ycombinator.com/item?id=26547279
| dorianmariefr wrote:
| Will it also be a vulnerability in boringssl and libressl? only
| speculations
| ollien wrote:
| Not that there's much to read here, but here's an archive link
|
| https://web.archive.org/web/20210322203019/https://mta.opens...
| jez wrote:
| Site appears to be hugged to death. Here's the full text of the
| email: The OpenSSL project team would like to
| announce the forthcoming release of OpenSSL version
| 1.1.1k. This release will be made available on
| Thursday 25th March 2021 between 1300-1700 UTC.
| OpenSSL 1.1.1k is a security-fix release. The highest severity
| issue fixed in this release is HIGH:
| https://www.openssl.org/policies/secpolicy.html#high
| Yours The OpenSSL Project Team
|
| https://web.archive.org/web/20210322203019/https://mta.opens...
| seaghost wrote:
| I often ask myself how long these things are exploited in the
| wild before they get revealed.
| interestica wrote:
| And I ask myself if announcing a fix with a few days lead time:
| 1. increases searches for the exploit 2. causes those with the
| exploit to utilize it as often as possible before its planned
| enddate.
| tptacek wrote:
| The last sev:hi OpenSSL vulnerability was an X.509 null pointer
| read, crash-only, just in case you're calibrating expectations.
| orblivion wrote:
| Do they usually give 3 days lead time? That's what gets my
| attention here.
| bcaa7f3a8bbc wrote:
| Yes, all HIGH severity vulnerabilities (even MODERATE) have
| lead time.
|
| e.g. see https://mta.openssl.org/pipermail/openssl-
| announce/2021-Febr...
| spockz wrote:
| I really like the lead time. It gives everyone time to
| prepare to patch ASAP when it is released without having
| the vulnerability available to attackers through diffing
| the binary.
|
| On the other hand, it gives people that found the
| vulnerability independently a bit of extra time to exploit.
| koolba wrote:
| > It gives everyone time to prepare to patch ASAP when it
| is released without having the vulnerability available to
| attackers through diffing the binary.
|
| It's an open source library so the code of the patch will
| be available as soon as it's published. It's not released
| as a compiled library.
| smasher164 wrote:
| Looking forward to the day that Evercrypt[1] becomes a
| production-ready replacement for libcrypto.
|
| [1] https://hacl-star.github.io/HaclValeEverCrypt.html
| dochtman wrote:
| I am a maintainer for rustls (https://github.com/ctz/rustls).
|
| What would your team need to be able to migrate to a different
| TLS stack that so far has proven to be safer, and passed its
| first security audit with flying colors?
| (https://github.com/ctz/rustls/blob/main/audit/TLS-01-report....)
|
| (I am also currently available on part-time freelance basis, feel
| free to contact me if you need commercial support on your
| endeavour to structurally address your TLS security issues.)
| sounds wrote:
| Apps build rustls into a fat binary, which doesn't get updated
| on day zero by the OS package manager. It requires a new
| release by the app maintainer for each app.
| tedunangst wrote:
| TLS 1.0 support.
| ancarda wrote:
| What do you need TLS 1.0 support for?
| tedunangst wrote:
| Talking to things that only support TLS 1.0. :( some old
| mail thing which doesn't know what year it is. I think min
| TLS 1.2 is probably fine for a new library, but I also
| think believing it's universal is pretty web centric.
| Snawoot wrote:
| Feature completeness. There is no reason to preserve only ECDH-
| based cipher suites, for example.
| ancarda wrote:
| Any idea when rustls will hit 1.0? I feel a little unsafe using
| a <1.0 library because (assuming it's following SemVer) as it
| might not be "done"/production ready and the API might change a
| lot before it hits 1.0.
| dochtman wrote:
| The API has generally been pretty stable, so I don't think
| you should be too worried about that. I haven't talked to
| other stakeholders about a version 1.0, and we actually have
| some larger API changes cooking right now. For now we
| probably value the ability to change the API more, especially
| because there are likely still ways we can make it more
| robust/secure.
| astrange wrote:
| The interesting thing about TLS state machine bugs is that they
| seem hard to prove nonexistence of ahead of time.
|
| Look at gotofail:
| https://www.imperialviolet.org/2014/02/22/applebug.html
|
| You can find it if you have a generic "suspicious looking code"
| check. And you can find it if you have a protocol regression
| test. But do you have a model of TLS that proves incorrect code
| paths like this don't exist?
| dochtman wrote:
| We have some documentation on what we've done to learn from
| previous vulnerabilities:
|
| https://docs.rs/rustls/0.19.0/rustls/manual/index.html
|
| We try very hard to model our code as a constrained state
| machine that closely follows the specification.
| CameronNemo wrote:
| Do you support ppc64le? WebAssembly? Not a requirement for me,
| but the fact that ring has no portable implementations is
| concerning. How do you verify correctness without a baseline?
| Evercrypt seems like a much better option on that front.
| dochtman wrote:
| I think _ring_ does support WebAssembly. Yeah, the ASM in
| _ring_ is not great, but unfortunately Rust does not
| currently provide us with all the guarantees we need to write
| safe crypto code (for example, timing guarantees). We hope
| this will change fairly soon, though, so we can port all the
| underlying crypto to Rust.
| 29athrowaway wrote:
| As soon as it becomes popular, it will be backdoored for sure.
| snvzz wrote:
| We should all have switched to libressl a long, long time ago.
|
| For some reason, companies decided to put money into the known-
| bad openssl instead, as if money could fix a bad development
| culture.
| tptacek wrote:
| I would probably use OpenSSL in preference to LibreSSL at this
| point. The dev culture point you're trying to make hasn't
| really been true for many years.
| tubbyjr wrote:
| Somewhat ironically to this circumstance (assuming it doesn't
| affect LibreSSL), the Void team has just switched back away
| from LibreSSL which it shipped by default with for years.
|
| Discussion: https://github.com/void-linux/void-
| packages/issues/20935
| spijdar wrote:
| AFAIK every other linux distro shipping with or providing
| options for LibreSSL also switched around the same time
| frame, e.g. Gentoo dropped all support for it. It's just not
| feasible to build 3rd party software (that are targeting
| OpenSSL) with it anymore (obviously, if you targeted libressl
| specifically, there's no problem, but almost nothing does).
| Maintainers have just gotten tired of writing giant patches
| to get things like Qt5 working again.
___________________________________________________________________
(page generated 2021-03-22 23:03 UTC)