3 ms·

You're really claiming this is a universal truth? Do you think it applies to OpenSSL? Chromium?

by jefftk 6y ago

ntauthority 6y ago
For cryptography one should just be able to rely on their OS' library, and depending on a full browser with high amounts of code churn, no compatibility for implementation code and a large dependency graph of its own is not really seen as a good thing in this context at all.
- jefftk 6y ago
  Let's be more specific: do you think Brave would be better off if they hard forked Chromium?
Godel_unicode 6y ago
Chromium ships with Windows and is maintained by Microsoft. Use the OS crypto library.
- jefftk 6y ago
  libjpeg? Specifically, I think hard forking is a bad idea for any sort of library that needs to be regularly updated for compatibility or security reasons.
  - Godel_unicode 6y ago
    That's possibly true if you don't have headcount for doing that maintenance. If you have appropriately planned for it however, it's just more software that you're writing to do the work you need done. If you're depending on some random person on the internet to update software which underlies your whole stack, then when the next imagetragick drops you can't update until they get around to fixing it. Since you won't have developers familiar with the code, fixing it won't likely be feasible for you. That's a lot of risk.
pwdisswordfish4 6y ago
I didn't say it was universal. OpenSSL and Chromium are outside the scope of "CDNs for external JavaScript libraries". (I actually included the appropriate hedging to clarify that my comments are scope-locked to that topic and to prevent digressions like this, but I edited it out because it made the comment too hard to read. Goes to show...)
- jefftk 6y ago
  Reading your "the cost of forking a third-party library and maintaining it in-house solely for your own use is no higher than the cost of relying on the third-party's unforked version" I didn't realize at all that you were trying to only talk about JavaScript that runs client side. I think your deleted clarification would have been helpful!
  - pwdisswordfish4 6y ago
    > I didn't realize at all that you were trying to only talk about JavaScript that runs client side Well, not just client-side JS; server-side, too, or anywhere that NPM is used, but even more than that: e.g. other package managers that were influenced by or work similarly to NPM and encourage a similar package-driven development style, e.g. Rust's crates.io or the Go community's comfortability with importing by URL. It applies for many of those cases, too, it just wasn't the focus of my comment.

You're really claiming this is a universal truth? Do you think it applies to OpenSSL? Chromium?

by jefftk 6y ago

You're really claiming this is a universal truth? Do you think it applies to OpenSSL? Chromium?

For cryptography one should just be able to rely on their OS' library, and depending on a full browser with high amounts of code churn, no compatibility for implementation code and a large dependency graph of its own is not really seen as a good thing in this context at all.

jefftk 6y ago
Let's be more specific: do you think Brave would be better off if they hard forked Chromium?

Godel_unicode 6y ago

Chromium ships with Windows and is maintained by Microsoft. Use the OS crypto library.

jefftk 6y ago
libjpeg? Specifically, I think hard forking is a bad idea for any sort of library that needs to be regularly updated for compatibility or security reasons.
- Godel_unicode 6y ago
  That's possibly true if you don't have headcount for doing that maintenance. If you have appropriately planned for it however, it's just more software that you're writing to do the work you need done. If you're depending on some random person on the internet to update software which underlies your whole stack, then when the next imagetragick drops you can't update until they get around to fixing it. Since you won't have developers familiar with the code, fixing it won't likely be feasible for you. That's a lot of risk.

pwdisswordfish4 6y ago

I didn't say it was universal. OpenSSL and Chromium are outside the scope of "CDNs for external JavaScript libraries". (I actually included the appropriate hedging to clarify that my comments are scope-locked to that topic and to prevent digressions like this, but I edited it out because it made the comment too hard to read. Goes to show...)

jefftk 6y ago
Reading your "the cost of forking a third-party library and maintaining it in-house solely for your own use is no higher than the cost of relying on the third-party's unforked version" I didn't realize at all that you were trying to only talk about JavaScript that runs client side. I think your deleted clarification would have been helpful!
- pwdisswordfish4 6y ago
  > I didn't realize at all that you were trying to only talk about JavaScript that runs client side Well, not just client-side JS; server-side, too, or anywhere that NPM is used, but even more than that: e.g. other package managers that were influenced by or work similarly to NPM and encourage a similar package-driven development style, e.g. Rust's crates.io or the Go community's comfortability with importing by URL. It applies for many of those cases, too, it just wasn't the focus of my comment.