On Fri, Apr 06, 2018 at 04:23:02PM +0200, Andy Polyakov wrote: > > This is one reason why keeping around old assembly code can have a cost. :( > > > > https://github.com/openssl/openssl/pull/5320 > > There is nothing I can add to what I've already said. To quote myself. > "None of what I say means that everything *has to* be kept, but as > already said, some of them serve meaningful purpose..." > > Well, I also said that "I'm *not* saying that bit-rot is not a concern, > only that it's not really assembly-specific." And I can probably add > something here, in addition to already mentioned example of legacy code > relying on formally undefined or implementation-specific behaviour. It's > not actually that uncommon that *new* C code is committed[!!!] > "bit-rotten". So one can *just as well* say that supporting another > operating system has a cost, and so does using another compiler... Why > not get "angry" about that? What's the difference really? Relevant
Yes, supporting another operating system has a cost! At risk of drawing Richard's ire, if we did not intend to support (e.g.) VMS, we might have been able to get away with not writing our own custom build system in favor of some "industry standard". Supporting non-POSIX systems (e.g., Windows) also adds overhead in how we implement many of our interfaces (file handling, thread handling, locking, randomness, etc.). I personally prefer a more conservative/restrictive approach than the historical trend, and probably also more conservative than the average of the team. This is presumably shaped by my personal experiences and career trajectory, and I understand that others' path are different and so they will have different, but still valid, preferences. We as a team are charged with weighing the tradeoff of supporting an additional platform against the burden of supporting it and the risks against our ability to continue supporting it. For example, in this modern world where properly supporting a platform basically does require some assembly code, for crypto-relevant timing considerations, if only one person understands and will support that assembly code, that is a risk. Perhaps it's enough of a risk to make officially supporting that platform a bad idea; perhaps not -- it's just one factor that we must, as a whole, weigh and consider. Removing platform-specific assembly when not needed for security would seem to reduce the risk, and presumably improve the maintainability of the software as a whole. But I don't see a good way to not have these decisions all be made on a case-by-case basis. -Ben _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project