1. 26
  1. 7

    Note: This is copied from my comment on the orange site.

    I appreciate this article bacause this is an important distinction to make. In fact, it is so important that I am willing to rewrite code in order to know the names and contact information of all of the people that my dependencies depend on, as well as having some sort of professional relationship with them.

    For example, in a project I am working on, I need a database, a way to talk over the Internet, and cryptography. Obviously, I know what database to use: SQLite (D. Richard Hipp). Obviously, I know what dependency to use for talking over the Internet: curl (Daniel Stenberg).

    Cryptography is harder, but I finally settled on BearSSL (Thomas Pornin). BearSSL does not give me everything I want, however; since I want OPAQUE (a way for clients to not give their password to a potentially malicious server), I need that. BearSSL also does not give me a “KSF,” or key-stretching function, which OPAQUE requires, though I can use Argon2i for that.

    The reference implementation for Argon2i unfortunately seems dead, even though I know the names of the people who made it. I don’t know if they will respond if I contact them, while I do know that D. Richard Hipp, Daniel Stenberg, and Thomas Pornin will respond. So in order to make sure I always have a point of contact with all of my dependencies, I am going to write Argon2i, BLAKE2b (needed by Argon2i), and OPAQUE myself.

    Bad idea? Yeah, don’t roll your own crypto. But I am studying hard, and I intend to get my crypto audited before publishing.

    The end result, however, is very worth it: my dependencies will be well-known, and I know each of the authors personally, albeit through email.

    And down the road, if I manage to make some money, I can kick some of it back to them in exchange for their previous help. In turn, they’ll be happy to continue the relationship.

    That’s how Open Source works at its best: it depends on relationships, and on giving back to those relationships. I think that that is what this article is trying to say, and I whole-heartedly agree.

    1. 7

      What you’ve written resonates with me, but it seems to push a lot of people to the side. People with families may not have the time to learn the algorithmic details of say, BLAKE2d. Others with learning difficulties or large knowledge gaps in the thing they want to recreate may never be able to achieve an implementation in a reasonable amount of time.

      And then there’s the other side: maybe these FOSS authors really don’t want to know you. Maybe the truth is, they write software because they like it, feel a sense of real achievement due to being helpful to humanity, but want nothing more. The semi-recent events of authors being ridiculed for “lack of support” is a similar example of “don’t bother me”.

      Trust though is huge and that’s why we have digital signatures for software packages, source code tarballs, and whatever else we want to maybe trust. I think the motto “don’t trust, verify” is heavily underrated, and should be applied more diligently to our dependencies. I believe this tool is helping with that.

      The context will determine the degree of trust you require.

      1. 2

        You bring up good points. And yet…

        As it so happens, I have a wife. I have very little time, and I have knowledge gaps in cryptography. I am not going to be able to do this in a reasonable amount of time. Yet I am still doing it because I feel strongly about doing my software right. Not many people want to. I do want to, and I am betting that once I do publish something, people would want to use it.

        As I mentioned on the orange site, I already have an email relationship with two of the three programmers. All three of them make their money off of the particular software I am going to use as dependencies (well, one makes their money off of consulting in the same area as the software he made), so if all else fails, I can throw money at them in the same way that others already do.

        That’s why my three requirements for dependencies included some way to pay for something. First, as TFA says, that’s important for Open Source, and second, it will probably be important to my business later.

        And as for trust, well, if I have paid them, part of the product I will pay them for is to have them declare that their software is fit for my purposes. (Basically, to nullify the “no warranty” clause of licenses, so I would have some sort of warranty.) While that doesn’t take care of the problem, there are laws that govern the use of warranties, so I would have some recourse. And when they take money from me, they would probably have more incentive to keep me happy, i.e., they would have incentive to be trustworthy.

        Still not enough for complete trust, but hey, it’s only three dependencies. That makes it easier to audit them personally.

        1. 4

          Yet I am still doing it because I feel strongly about doing my software right.

          Devil’s advocate: And so any other way is doing software wrong?

          I already have an email relationship with two of the three programmers.

          So in this particular case it’s possible / they accept relationships, but this isn’t true of all scenarios…

          The trust part yeah, there are a lot of ways to approach it. I wasn’t dismissing anything you said, just augmenting it with my own comment 🙂

          Thank you for the insightful conversation! Makes you think.

          1. 2

            Devil’s advocate: And so any other way is doing software wrong?

            If you’re paid for it, yes. If not, no. But I do want to be paid for mine eventually. Like the three fellows I will be depending on.

            So in this particular case it’s possible / they accept relationships, but this isn’t true of all scenarios…

            Correct. I had to do the leg work first before deciding on them. And if they decide to cut me off, I’m going to have to replace their software with something else or write it myself.

            Thank you for the insightful conversation! Makes you think.

            You’re welcome. And thank you. :)

            1. 1

              If you’re paid for it, yes

              This just in: getting paid is bad. I think respecting licenses and creating software off the works of others is how we advance as a society (and indeed, is how countless other creative pursuits have evolved). Purists in this respect don’t usually get very far is my cynical take here.

        2. 2

          People with families may not have the time to learn the algorithmic details of say, BLAKE2d.

          Implementing BLAKE2b is only a couple hours of work using the documentation provided and less than 1KSLOC 200SLOC. Packages like that are the easiest to write and maintain.

          1. 2

            is only a couple hours of work using the documentation provided

            You missed “for me” somewhere in there

            1. 0

              What you’ve written resonates with me, but it seems to push a lot of people to the side.

              If you aren’t willing to do the work then your opinion can be pushed to the side.

              1. 1

                What if you’re willing but unable?…