4 ms·

It's better if the new maintainer's intentions are altruistic. From @dominictarr, the maintainer: > he emailed me and said he wanted to maintain the module, so

It's better if the new maintainer's intentions are altruistic. From @dominictarr, the maintainer: > he emailed me and said he wanted to maintain the module, so I gave it to him. I don't get any thing from maintaining this module, and I don't even use it anymore, and havn't for years. That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common software libraries is becoming a very popular attack vector. Owners of these need to be a little more diligent when transferring ownership. Perhaps there should be some sort of escrow jail for new maintainers where all changes are reviewed. Certainly better vetting needs to take place.

i_cant_speel 8y ago
> Perhaps there should be some sort of escrow jail for new maintainers where all changes are reviewed That wouldn't really solve the problem. Attackers would just have to wait a bit longer before they push malicious code.
eropple 8y ago
It is irresponsible if you believe--and I don't say this pejoratively or to caricature the argument--that somebody takes upon themselves a responsibility when they open-source software. I used to think this was the case, but less and less often I find this to be true. In a practical sense it becomes a free-rider problem and people with money aren't stepping up. In the absence of accepted responsibility from (monied) consumers, the way responsibility is ultimately taken on has to be either to affirmatively take it on (as public service to the community) or to pay for it. Which is a sticky problem because it's hard to pay for it and it's invariably not presented effectively in terms of building a business case. Existing solutions, not to put too fine a point on it, suck at building that case. OpenCollective, the remnants of Gittip/Gratipay, etc. - incentives don't align to put money where it needs to go, and J. Random Consumer often suffers the most for it. I have a pretty strong idea about how to solve it for-reals. At the moment, though, it's a time/money problem for me; I'm not in a place to chase the kind of (relatively small) funding that the problem probably requires. If anyone else is interested in this problem space, please feel free to email me directly; I'd be happy to chat with you and I'm very interested in seeing this done well.
_wmd 8y ago
This is entitlement speaking, and it's clearly a solution that doesn't scale. Downstream must be responsible for only depending on software from reputable sources, there simply is no alternative. I hate to have to do this, but the requirement runs right to the core of how this development model functions whatsoever: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. I'd suggest one problem here is a user interface / packaging model issue: end users / downstreams may override the version choices made by their upstream dependencies. In the case here, the reputability of that upstream varied over time. Permitting version locking allows a chain of reputability to be exist, allowing a limited amount of trustworthiness to be imparted by upstream's selection of dependencies ("I trust this guy's package, so I trust all their dependencies too")
- eeZah7Ux 8y ago
  > Downstream must be responsible for only depending on software from reputable sources, there simply is no alternative. The alternative is to use distributions that do vetting and staging.
  - JustSomeNobody 8y ago
    No, there is no alternative. You are responsible for what you ship. Even if you pay for the software, you should vet it as best you can as you're responsible.
    - jodrellblank 8y ago
      How are you going to have the time and skill to vet Oracle anything?
      - 8y ago
reacweb 8y ago
Maybe it should be easier to give monetary rewards so that popular module maintainers get more motivation to care.
- jodrellblank 8y ago
  Claims here are that dominictarr maintains "hundreds of packages" even though that's too much work for one person. If maintaining modules earned money, that would be much more incentive to "maintain" thousands of random things you never look at, and to hand over control while keeping it in your name (which he's also being blamed for).
elorm 8y ago
So if I understand you correctly, he was supposed to have run some sort of background check with all the state agencies to figure out if he was a bad actor or someone who really relied on the module and wanted to maintain it. You can’t protect against all possible outcomes from a situation like this. Seems like we’re just looking for people to blame whenever there’s an issue these days
- ddingus 8y ago
  Free lunch tasted bad? And let's not blame the free lunch people who are always on the hunt for people and ingredients needed to put together free lunches. Paying for a better, more consistent lunch makes sense at some point, yes? People are motivated to work, ingredients are vetted, better prepared, etc... Not blaming anyone, just pointing out an obvious problem by analogy.
- michaelmrose 8y ago
  He should just not allow any party not known and trusted to distribute under the original product name. Let it be known that it's discontinued and let the new maintainer trade on his own reputation.
notyourday 8y ago
> That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common software libraries is becoming a very popular attack vector. Owners of these need to be a little more diligent when transferring ownership. I'm sure he would do it for $150k/year. He won't do it for $150k/year? Increase the price until he says "Yeah, sure I will maintain it". Or maybe he will find someone else would would maintain it for that money.
- michaelmrose 8y ago
  How about just not transfer ownership of the original name. Let foo become foo-new or go from john/foo to bob/foo whichever is appropriate thus ensuring that only those who affirmatively added bob/foo or foo-new are ever effected. Vetting new maintainers sounds like hard work that you might not feel like doing for free no problem just don't do it and don't give them the damn name.
  - bigmanwalter 8y ago
    That's fundamentally not how identification on the Internet works. You are whoever you say you are. It's absurd to tie identity to a physical person.
    - michaelmrose 8y ago
      You are incorrect you are who you can prove who you are. I can prove any of a number of identities scattered around the internet most of which are in fact my real name. Pretending that this is trust less is just not real. Example I know from a wide variety of sources that certain projects are trustworthy even if I can only verify a pseudonym that itself is trustworthy and infer that authors other projects are trustworthy. Accounts emails and domains are all useful tools even if not perfect. People don't normally put years into developing trust in order to distribute malware. It's normally a low effort affair. Not giving maintainership to random people who send you an email or selling projects to skeevy companies seems like a good way to avoid 80% of issues kind of like washing your hands can prevent a lot of colds.

i_cant_speel 8y ago

> Perhaps there should be some sort of escrow jail for new maintainers where all changes are reviewed That wouldn't really solve the problem. Attackers would just have to wait a bit longer before they push malicious code.

eropple 8y ago

It is irresponsible if you believe--and I don't say this pejoratively or to caricature the argument--that somebody takes upon themselves a responsibility when they open-source software. I used to think this was the case, but less and less often I find this to be true. In a practical sense it becomes a free-rider problem and people with money aren't stepping up. In the absence of accepted responsibility from (monied) consumers, the way responsibility is ultimately taken on has to be either to affirmatively take it on (as public service to the community) or to pay for it. Which is a sticky problem because it's hard to pay for it and it's invariably not presented effectively in terms of building a business case. Existing solutions, not to put too fine a point on it, suck at building that case. OpenCollective, the remnants of Gittip/Gratipay, etc. - incentives don't align to put money where it needs to go, and J. Random Consumer often suffers the most for it. I have a pretty strong idea about how to solve it for-reals. At the moment, though, it's a time/money problem for me; I'm not in a place to chase the kind of (relatively small) funding that the problem probably requires. If anyone else is interested in this problem space, please feel free to email me directly; I'd be happy to chat with you and I'm very interested in seeing this done well.

_wmd 8y ago

This is entitlement speaking, and it's clearly a solution that doesn't scale. Downstream must be responsible for only depending on software from reputable sources, there simply is no alternative. I hate to have to do this, but the requirement runs right to the core of how this development model functions whatsoever: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. I'd suggest one problem here is a user interface / packaging model issue: end users / downstreams may override the version choices made by their upstream dependencies. In the case here, the reputability of that upstream varied over time. Permitting version locking allows a chain of reputability to be exist, allowing a limited amount of trustworthiness to be imparted by upstream's selection of dependencies ("I trust this guy's package, so I trust all their dependencies too")

eeZah7Ux 8y ago
> Downstream must be responsible for only depending on software from reputable sources, there simply is no alternative. The alternative is to use distributions that do vetting and staging.
- JustSomeNobody 8y ago
  No, there is no alternative. You are responsible for what you ship. Even if you pay for the software, you should vet it as best you can as you're responsible.
  - jodrellblank 8y ago
    How are you going to have the time and skill to vet Oracle anything?
    - 8y ago

reacweb 8y ago

Maybe it should be easier to give monetary rewards so that popular module maintainers get more motivation to care.

jodrellblank 8y ago
Claims here are that dominictarr maintains "hundreds of packages" even though that's too much work for one person. If maintaining modules earned money, that would be much more incentive to "maintain" thousands of random things you never look at, and to hand over control while keeping it in your name (which he's also being blamed for).

elorm 8y ago

So if I understand you correctly, he was supposed to have run some sort of background check with all the state agencies to figure out if he was a bad actor or someone who really relied on the module and wanted to maintain it. You can’t protect against all possible outcomes from a situation like this. Seems like we’re just looking for people to blame whenever there’s an issue these days

ddingus 8y ago
Free lunch tasted bad? And let's not blame the free lunch people who are always on the hunt for people and ingredients needed to put together free lunches. Paying for a better, more consistent lunch makes sense at some point, yes? People are motivated to work, ingredients are vetted, better prepared, etc... Not blaming anyone, just pointing out an obvious problem by analogy.
michaelmrose 8y ago
He should just not allow any party not known and trusted to distribute under the original product name. Let it be known that it's discontinued and let the new maintainer trade on his own reputation.

notyourday 8y ago

> That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common software libraries is becoming a very popular attack vector. Owners of these need to be a little more diligent when transferring ownership. I'm sure he would do it for $150k/year. He won't do it for $150k/year? Increase the price until he says "Yeah, sure I will maintain it". Or maybe he will find someone else would would maintain it for that money.

michaelmrose 8y ago
How about just not transfer ownership of the original name. Let foo become foo-new or go from john/foo to bob/foo whichever is appropriate thus ensuring that only those who affirmatively added bob/foo or foo-new are ever effected. Vetting new maintainers sounds like hard work that you might not feel like doing for free no problem just don't do it and don't give them the damn name.
- bigmanwalter 8y ago
  That's fundamentally not how identification on the Internet works. You are whoever you say you are. It's absurd to tie identity to a physical person.
  - michaelmrose 8y ago
    You are incorrect you are who you can prove who you are. I can prove any of a number of identities scattered around the internet most of which are in fact my real name. Pretending that this is trust less is just not real. Example I know from a wide variety of sources that certain projects are trustworthy even if I can only verify a pseudonym that itself is trustworthy and infer that authors other projects are trustworthy. Accounts emails and domains are all useful tools even if not perfect. People don't normally put years into developing trust in order to distribute malware. It's normally a low effort affair. Not giving maintainership to random people who send you an email or selling projects to skeevy companies seems like a good way to avoid 80% of issues kind of like washing your hands can prevent a lot of colds.