Clarify contribution guidelines/"awesomeness" criteria

[nodiscc]

Followup to #357 (add PiVPN)

---

@nodiscc

curl | bash

Software that uses this installation method used to be rejected under the previous maintainer (https://github.com/awesome-foss/awesome-sysadmin/pulls?q=is%3Apr+pivpn+is%3Aclosed). This guideline was never written down but I don't want to change the way the list is maintained right now (it's currently on minimal maintenance mode awesome-selfhosted/awesome-selfhosted#2482, I'm just doing some cleanup).

I know I would personally never use this method (I understand it's just a matter of downloading the install script first, inspecting it, then running it, but then the documentation should mention it explicitly).

This is more of an open question, what guidelines should be added to keep the list high quality? From the past list of issues I remember these ideas:

• the program must be mature enough (e.g. old enough to be in Debian Stable)
• usable in a professional setup
• have a decently sized community of users or contributors
• no curl | bash
• ...?

Feedback welcome.

---

@jadolg

IMO the curl | bash thing is a bit arbitrary.
There are other installation methods listed right there and it's not like you can't read what you are installing if you actually want to.
I know you "should not" just curl | bash for security reasons, but most people (even being able to read what they are going to execute) are not going to analyze a thing.

---

@xrat

I'd like to add a reminder to the discussion of list quality, namely the distinction of sysadmin vs. superuser vs. beginner. At least 1 of these is supposed to know the implications of curl | bash.

---

@nodiscc

distinction of sysadmin vs. superuser vs. beginner

In my opinion this list should stay a resource intended for professional sysadmins, or at least people striving to implement setups of professional quality.

you "should not" just curl | bash for security reasons, but most people are not going to analyze a thing.

Which is a huge no-go in professional environments (not analyzing what's being run). Hence software for which curl | bash is the only documented installation method should not be included, in my opinion.

Other opinions regarding criteria for inclusion are welcome (see comments above).

Related #429

---

@xrat

Hence software for which curl | bash is the only documented installation method should not be included, in my opinion.

I understand your point of view, and I do not disagree, however, as a professional sysadmin I am quite able to appreciate installation instructions based on a (furthermore likely well-tested) shell script. In fact, it so happened that I got notice of PiVPN thanks to this pull request. I reviewed its install.sh and went with it. I have to say, though, that its 3k lines is not a trivial perusal.

Concluding, while I personally don't mind curl | bash, I agree it should not be the only documented installation method.

---

@OckhamOdyssey

I don't understand why not accept the PR just because they document the curl | bash. PiVPN is secure by default and have pretty good scripts to manage the clients certifications, specially for large number of users. They have the git clone option.

but most people (even being able to read what they are going to execute) are not going to analyze a thing.

If we are going to follow that logic, thinking in the very beginners users, we should delete so many programs of the list because the documentation doesn't say "remember to check the code before executing".

---

@nodiscc

The criteria from OpenSSF Best Practices are good indicators of quality in FOSS projects. You can see a list of projects and their scores at https://bestpractices.coreinfrastructure.org/en/projects.

Note that the use of curl | bash is NOT explicitely forbidden by these guidelines. The closest thing I could find is

The project MUST use a delivery mechanism that counters MITM attacks. Using https or ssh+scp is acceptable.

So if we go by this, curl | bash would be acceptable as long as the URL is a HTTPS one. There is another guideline in the silver level criteria that states

The project MUST cryptographically sign releases of the project results intended for widespread use, and there MUST be a documented process explaining to users how they can obtain the public signing keys and verify the signature(s). The private key for these signature(s) MUST NOT be on site(s) used to directly distribute the software to the public.

Of course curl | bash installation scripts imply the absence of cryptographic signatures, but a lot of projects using other installation methods do not provide signatures either, so if we started requiring this, a lot of software currently present in the list would not qualify.

In light of all this, and the other comments here, I don't think curl | bash as recommended installation method automatically makes the software "not awesome". /cc @n1trux

We should still find clear criteria for what is considered "awesome enough" or not. Feedback still welcome.

---

@nodiscc

The review in #449 yielded good results, I asked a few questions which resulted in constructive answers from @kosli:

Have you used it? For how long?
Is this in a personal or professional setup?
How many devices do you manage with it?
Biggest pros/cons compared to other solutions?
Any other comments about your use case, things you've found excellent, limitations you've encountered... ?

I am using it since a few weeks in a professional setup and I am very happy and looking into contributing myself as I want to make some features that I need.
Currently I have only 5 routers (PC engines apu boards) in the system, but have ~400 devices running in my own system that I will migrate over time into OpenWISP.a
I accidentally found OpenWISP when I was looking into a new OS for my routers (OpenWRT) and I am very impressed by the feature-rich, well-build platform that can easily be extended.

I think this is the kind of questions we could include in the pull request template.

---

@nodiscc

Good results as well in #457 and #453. I'll make a Pull Request to add these questions to the template (done: #459), and move this discussion to a dedicated issue.