OS requirements/page: add a security tracker? (and otherwise think of the OS requirements) #1370

New Issue

2019-10-01T13:30:14Z

Mikaela commented

2019-10-01 13:30:14 +00:00

(Migrated from github.com)

OSes

Must state if recommends, depends on, or offers non-free software (contrib)

No Tracking Policy (opt-in analytics is ok)

d344dffd0b/.github/CONTRIBUTING.md (oses)

I would like to add requirement for having a security tacker or posting security advisories and list them on the OS page as currently there is nothing to judge their security or response to security issues from.

> OSes > * Must state if recommends, depends on, or offers non-free software (contrib) > * No Tracking Policy (opt-in analytics is ok) * https://github.com/privacytoolsIO/privacytools.io/blob/d344dffd0b307b04bfaa579e43c201d52c590d02/.github/CONTRIBUTING.md#oses I would like to add requirement for having a security tacker or posting security advisories and list them on the OS page as currently there is nothing to judge their security or response to security issues from.

Mikaela commented

2019-10-01 13:43:23 +00:00

(Migrated from github.com)

https://www.qubes-os.org/security/bulletins/
https://bodhi.fedoraproject.org/updates/?type=security ?
https://www.debian.org/security/index.en.html
https://www.openbsd.org/security.html
https://security.archlinux.org/
Parabola - unknown?
Trisquel - unknown?
https://forums.whonix.org/c/news - I don't know how applicable this is to Whonix?
https://tails.boum.org/security/index.en.html
KNOPPIX - unknown?
Puppy Linux - unknown? (SSL_ERROR_INTERNAL_ERROR_ALERT on puppylinux.org for me)
Tiny Core Linux - N/A ?

* https://www.qubes-os.org/security/bulletins/ * https://bodhi.fedoraproject.org/updates/?type=security ? * https://www.debian.org/security/index.en.html * https://www.openbsd.org/security.html * https://security.archlinux.org/ * Parabola - unknown? * Trisquel - unknown? * https://forums.whonix.org/c/news - I don't know how applicable this is to Whonix? * https://tails.boum.org/security/index.en.html * KNOPPIX - unknown? * Puppy Linux - unknown? (`SSL_ERROR_INTERNAL_ERROR_ALERT` on puppylinux.org for me) * Tiny Core Linux - N/A ?

Mikaela commented

2019-10-05 08:39:17 +00:00

(Migrated from github.com)

Should we also require that the OS is not owned by a business/corporation?

dawidpotocki commented

2019-10-05 08:58:56 +00:00

(Migrated from github.com)

Should we also require that the OS is not owned by a business/corporation?

Lol, no.

> Should we also require that the OS is not owned by a business/corporation? Lol, no.

Mikaela commented

2019-10-13 08:26:44 +00:00

(Migrated from github.com)

One requirement is probably at least having microcode updates available as we have rejected some based on that? https://github.com/privacytoolsIO/privacytools.io/issues/1404

dawidpotocki commented

2019-10-13 08:53:21 +00:00

(Migrated from github.com)

One requirement is probably at least having microcode updates available as we have rejected some based on that?

That would exclude fully free distros, right?

> One requirement is probably at least having microcode updates available as we have rejected some based on that? That would exclude fully free distros, right?

Mikaela commented

2019-10-13 09:05:53 +00:00

(Migrated from github.com)

That would exclude fully free distros, right?

I don't know, did anyone ever find out how do they handle microcode? And we have already been closing them out with microcode being a factor in https://github.com/privacytoolsIO/privacytools.io/issues/936#issuecomment-493655147, https://github.com/privacytoolsIO/privacytools.io/pull/978#pullrequestreview-247364516 and https://github.com/privacytoolsIO/privacytools.io/issues/1146#issuecomment-520619725.

Quoting @blacklight447-ptio from the last one:

Would it be a good plan to own the proprietary software industry and protect your privacy by forcing yourself to run outdated insecure code? Perhaps not. While its generally a good thing to know what your system runs, and it generally helps you enhance your privacy, just because code is closed source, doesn't always mean its bad for you.

> That would exclude fully free distros, right? I don't know, did anyone ever find out how do they handle microcode? And we have already been closing them out with microcode being a factor in https://github.com/privacytoolsIO/privacytools.io/issues/936#issuecomment-493655147, https://github.com/privacytoolsIO/privacytools.io/pull/978#pullrequestreview-247364516 and https://github.com/privacytoolsIO/privacytools.io/issues/1146#issuecomment-520619725. Quoting @blacklight447-ptio from the last one: > Would it be a good plan to own the proprietary software industry and protect your privacy by forcing yourself to run outdated insecure code? Perhaps not. While its generally a good thing to know what your system runs, and it generally helps you enhance your privacy, just because code is closed source, doesn't always mean its bad for you.

dngray commented

2020-05-05 18:31:56 +00:00

(Migrated from github.com)

Should we also require that the OS is not owned by a business/corporation?

This would serve no purpose.

If we do want to make a requirement, a sensible one would be reproducible builds with continuous tests.

The other requirement I would make is to only recommend mainstream distributions, and not ones designed to run on specific OEM hardware.

One requirement is probably at least having microcode updates available as we have rejected some based on that? #1404

Microcode updates should be applied. They often fix critical security flaws. Yes its a blob, accept it, you're on x86_64 and that is not a free platform.

Realistically purists complaining about microcode, but trusting the silicon is just silly.

Hopefully one day we will have a decent and affordable RISC-V platform. Until then I guess there is the POWER9 solutions from Raptor Computing Systems.

In regard to the topic at hand, I think a security tracker would be duplicating what distributors already provide. If you use a Debian based distro you should look at DSA, or trust your distribution is maintained well enough that you do not have to.

> Should we also require that the OS is not owned by a business/corporation? This would serve no purpose. If we do want to make a requirement, a sensible one would be [reproducible builds](https://reproducible-builds.org) with [continuous tests](https://reproducible-builds.org/citests/). The other requirement I would make is to only recommend mainstream distributions, and not ones designed to run on specific OEM hardware. > One requirement is probably at least having microcode updates available as we have rejected some based on that? #1404 Microcode updates should be applied. They often fix critical security flaws. Yes its a blob, accept it, you're on x86_64 and that is not a free platform. Realistically purists complaining about microcode, but trusting the silicon is just silly. Hopefully one day we will have a decent and affordable [RISC-V](https://en.wikipedia.org/wiki/RISC-V) platform. Until then I guess there is the POWER9 solutions from [Raptor Computing Systems](https://www.raptorcs.com/content/base/products.html). In regard to the topic at hand, I think a security tracker would be duplicating what distributors already provide. If you use a Debian based distro you should look at DSA, or trust your distribution is maintained well enough that you do not have to.

This repo is archived. You cannot comment on issues.