4 ms·

wow. this is such a bad take, it makes me question using Age at all. > tools should not have issues that need communicating to users, and if they did they shou

by 2h 4y ago

wow. this is such a bad take, it makes me question using Age at all. > tools should not have issues that need communicating to users, and if they did they should fix them, not delegate a choice to a user. no tool is perfect, including Age. and no issue is fixed immediately, or at all. so instead of waiting months or years for an issue to be fixed, it can be quite helpful to throw a quick warning on the front page, so at least people are warned in the meantime. Its just a sign of respect, and of not wasting the users time. > Imagine if every project came with a list of potential issues you have to form an opinion on I would be glad if more projects included important to-dos or shortcomings up front, so that I dont have to discover them myself after a week or month of use. Further, no one is forcing users to form an opinion, or even read the known issues. you throw them in a section at the bottom the of README, then they can read if they want, and form and opinion if they want. without doing this, you're essentially lying to the userbase, as you are aware of issues, perhaps even important ones, that are not fixed, and are purposefully hiding that information, or at least not being as forthcoming with it as you could be.

deleted 4y ago
[deleted]
d-z-m 4y ago
> wow. this is such a bad take, it makes me question using Age at all. I would think it would bolster your confidence in age, as the maintainer is expressing a commitment to fix issues as they arise, not punt indefinitely with TODOs at the bottom of a README. > > tools should not have issues that need communicating to users, and if they did they should fix them, not delegate a choice to a user. You stripped important context from the beginning of this quote, the original reads: > Security (and security-relevant) tools should not have issues that need communicating to users, and if they did they should fix them, not delegate a choice to a user. Which seems reasonable.
loup-vaillant 4y ago
You might want to read this paragraph from @FiloSottile: > The only reason to use more than 128 bits of key is to protect against multi-user attacks. […] There are two ways to protect against that: larger keys or nonces. age uses a 128-bit per-file nonce fed into HKDF, making the total search space 128 + 128 = 256 bits, safe in every multi-user scenario, too. This is big. Without those multi-user attacks Age is much safer than I initially thought. The tiny security increase we'd get by going to 256-bit keys is not worth making a breaking change. Not by itself at least.

by 2h 4y ago

deleted 4y ago

[deleted]

d-z-m 4y ago

> wow. this is such a bad take, it makes me question using Age at all. I would think it would bolster your confidence in age, as the maintainer is expressing a commitment to fix issues as they arise, not punt indefinitely with TODOs at the bottom of a README. > > tools should not have issues that need communicating to users, and if they did they should fix them, not delegate a choice to a user. You stripped important context from the beginning of this quote, the original reads: > Security (and security-relevant) tools should not have issues that need communicating to users, and if they did they should fix them, not delegate a choice to a user. Which seems reasonable.

loup-vaillant 4y ago

You might want to read this paragraph from @FiloSottile: > The only reason to use more than 128 bits of key is to protect against multi-user attacks. […] There are two ways to protect against that: larger keys or nonces. age uses a 128-bit per-file nonce fed into HKDF, making the total search space 128 + 128 = 256 bits, safe in every multi-user scenario, too. This is big. Without those multi-user attacks Age is much safer than I initially thought. The tiny security increase we'd get by going to 256-bit keys is not worth making a breaking change. Not by itself at least.