[LAD] https for linuxaudio.org

[David Runge]

Hey all,

I'm currently taking over a bunch of packages for Arch Linux (mainly
pro-audio stuff).
Would it be possible to implement letsencrypt for linuxaudio.org and all
of its subdomains?
This would greatly improve the security of the packages hosted there (or
rather their transfer from the server to the build machine) and help for
said packages not to be dropped, as more and more distros try to switch
to more reliable and authenticatable (is that a word?) upstreams.
Additionally, there is the benefit of raising privacy for users of all
things hosted on linuxaudio.org.

An example are all sources hosted here (all of which are packages in
Arch's main repos):
http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html

Best,
David

[Ralf Mardorf]

Post by David Runge
Would it be possible to implement letsencrypt for linuxaudio.org and
all of its subdomains?
This would greatly improve the security of the packages hosted there
(or rather their transfer from the server to the build machine) and
help for said packages not to be dropped, as more and more distros try
to switch to more reliable and authenticatable (is that a word?)
upstreams.

Hi,

for security reasons developers should consider to provide signed
checksums, as fortunately e.g.
https://www.kernel.org/category/signatures.html does. This was
discussed at e.g. Arch general.

Post by David Runge
Additionally, there is the benefit of raising privacy for users of all
things hosted on linuxaudio.org.

Not that much, since even when additionally using TOR, privacy isn't
ensured without exceptions,
https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting .

Regards,
Ralf

[Louigi Verona]

Yeah, more security and privacy, because Linux Audio packages are
constantly attacked by enemies :D

Post by Ralf Mardorf

Post by David Runge
Would it be possible to implement letsencrypt for linuxaudio.org and
all of its subdomains?
This would greatly improve the security of the packages hosted there
(or rather their transfer from the server to the build machine) and
help for said packages not to be dropped, as more and more distros try
to switch to more reliable and authenticatable (is that a word?)
upstreams.

Hi,
for security reasons developers should consider to provide signed
checksums, as fortunately e.g.
https://www.kernel.org/category/signatures.html does. This was
discussed at e.g. Arch general.

Post by David Runge
Additionally, there is the benefit of raising privacy for users of all
things hosted on linuxaudio.org.

Not that much, since even when additionally using TOR, privacy isn't
ensured without exceptions,
https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting .
Regards,
Ralf
--
$ pacman -Q linux{,-rt{,-cornflower,-pussytoes}}|awk '{print $2}'
4.14-2
4.13.13_rt5-1
4.11.12_rt16-1
4.14_rt1-1
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[Ralf Mardorf]

Post by Louigi Verona
Yeah, more security and privacy, because Linux Audio packages are
constantly attacked by enemies :D

Btw. packages of major distros are signed. It would make much more
sense, if upstream already would sign the tarballs providing the source
code, too.

[David Runge]

Hey Ralf,

Post by Ralf Mardorf
for security reasons developers should consider to provide signed
checksums, as fortunately e.g.
https://www.kernel.org/category/signatures.html does. This was
discussed at e.g. Arch general.

That is right. I am not sure, how many can be convinced in the near
future. Asking is cheap, though, so would that work for you Fons? :)

Post by Ralf Mardorf
Not that much, since even when additionally using TOR, privacy isn't
ensured without exceptions,
https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting .

That of course is also true and thanks for pointing it out.
When writing, I was more thinking of subdomains hosting applications,
that require authentication (then seeing, that e.g.
{lists,wiki}.linuxaudio.org already facilitate letsencrypt certs).

Of course, given the right tools and infrastructure, it gets
increasingly harder to achieve some form of privacy.
However, that's no reason not to aim for the maximum amount thereof.

In any case (unless your ssl is broken) and however one wants to turn
it: It is beneficial to implement https and I'm happy to hear it will be
done.

Best,
David

[Ralf Mardorf]

Post by David Runge

Post by Ralf Mardorf
Not that much, since even when additionally using TOR, privacy isn't
ensured without exceptions,
https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting .

That of course is also true and thanks for pointing it out.
When writing, I was more thinking of subdomains hosting applications,
that require authentication (then seeing, that e.g.
{lists,wiki}.linuxaudio.org already facilitate letsencrypt certs).
Of course, given the right tools and infrastructure, it gets
increasingly harder to achieve some form of privacy.
However, that's no reason not to aim for the maximum amount thereof.
In any case (unless your ssl is broken) and however one wants to turn
it: It is beneficial to implement https and I'm happy to hear it will
be done.

Btw. when I asked to provide Ardour for Arch with disabling the phone
home option, as Debian and Ubuntu already did, it was not because I had
concerns regarding upstream, I've done this, e.g. because activists use
Ardour and at the same time TOR browser, without redirecting all
traffic trough the onion. I'm pro ever little step to grant more
privacy by default, https is one of those steps. Actually ssl is much
known to the masses for Heartbleed, not for security and it's
kinda always in a broken state.

[***@archlinux ~]$ arch-audit | grep ssl
Package openssl-1.0 is affected by CVE-2017-3736, CVE-2017-3735. Medium risk!

Ok, no output for openssl yet, just for openssl-1.0, however taking a
look at...

[***@archlinux ~]$ pactree -r openssl-1.0
[snip]
[***@archlinux ~]$ pactree -r openssl
[snip]

...we should take in consideration that ssl isn't the universal
salvation.

But again, I agree with you, https is better than no https ;).

Regards,
Ralf

[Fons Adriaensen]

Post by David Runge
That is right. I am not sure, how many can be convinced in the near
future. Asking is cheap, though, so would that work for you Fons? :)

So that would mean:

- I create a GPG key for signing zita-packages, and make it
available on some keyserver.

- Some famous LAD members sign my key.

- I use gpg -b zita-zzz.tar.bz2 to generate a signature for
each package and put it on my website.

I see no problem with this.

Some questions:

- which keyserver to use ?
- use gpg -b or gpg -ab ?

Ciao,

[Ralf Mardorf]

Post by Fons Adriaensen
- which keyserver to use ?

In cases of doubt simply use keys.gnupg.net ;).

To get a key by alias or by scripts I'm using different key servers e.g. [1].
Aren't the servers synced? I guess it's just useful that "Some famous LAD
members sign" your key, not which server you use to upload your key.

[1]
[***@archlinux ~]$ grep hkp .bashrc
alias gkey='gpg --keyserver hkp://pgp.uni-mainz.de --recv-keys'
alias gkey2='gpg2 --keyserver hkp://keys.gnupg.net --recv-keys'
[***@archlinux ~]$ grep hkp luamd64_1610.sh
key gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys FBB75451 EFE21092

[Ralf Mardorf]

Post by Ralf Mardorf
key gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys FBB75451 EFE21092

I win praise for a script that downloads Ubuntu desktop flavours and
does all the signed key procedure, but it was criticized that I used
the key short ID.

https://lists.ubuntu.com/archives/lubuntu-users/2017-November/011741.html
https://lists.ubuntu.com/archives/lubuntu-users/2017-November/011747.html

Tricky ;).

[Jeremy Jongepier]

Hello David,

Post by David Runge
I'm currently taking over a bunch of packages for Arch Linux (mainly
pro-audio stuff).
Would it be possible to implement letsencrypt for linuxaudio.org and all
of its subdomains?

It's possible for linuxaudio.org but not for all the subdomains. the
linuxaudio.org server is a shared server that hosts projects of a
variety of organizations and people. ***@linuxaudio.org can't enforce
the usage of SSL for all users, it's a decision the users have to take.

Post by David Runge
This would greatly improve the security of the packages hosted there (or
rather their transfer from the server to the build machine) and help for
said packages not to be dropped, as more and more distros try to switch
to more reliable and authenticatable (is that a word?) upstreams.
Additionally, there is the benefit of raising privacy for users of all
things hosted on linuxaudio.org.
An example are all sources hosted here (all of which are packages in
http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.htm

That happens to be a subdomain ***@linuxaudio.org does not maintain,
you will have to ask the owner of that subdomain if implementing HTTPS
is an option. If the owner is OK with that ***@linuxaudio.org can
implement it.

Jeremy
***@linuxaudio.org

[IOhannes m zmoelnig]

Post by Jeremy Jongepier
Hello David,

Post by David Runge
I'm currently taking over a bunch of packages for Arch Linux (mainly
pro-audio stuff).
Would it be possible to implement letsencrypt for linuxaudio.org and all
of its subdomains?

It's possible for linuxaudio.org but not for all the subdomains. the
linuxaudio.org server is a shared server that hosts projects of a
the usage of SSL for all users, it's a decision the users have to take.

i'm not sure whether i read this correctly, but you make it sound like
there's technical problems hindering the implementation of https://,
although i think these are merely social (e.g. you don't want to shove
https:// down the throat of just anybody).
it's also slightly unclear what you mean by "users" (intuitively i would
have said that "users" refers to the people who want to access the
website with their browsers; however, as ***@linuxaudio.org you might
think of the 'variety of organizations and people' who host projects on
linuxaudio.org as your "users").

also, there's a slight difference between "enforcing the usage of SSL"
(shoving it down the throats of everybody) and "enabling" it.


https:// is a great means against mitm attacks; as ralf has pointed out,
it's less useful as a tool to ensure privacy (use tor for that) or
integrity (use gpg signatures for that). however, it does help raising
the standards for both.
there is practically no reason to *not* use https:// everywhere (well
there's one: CPU power on the server side).

if CPU power is not a problem, i would suggest to:
- enable https:// for *all* VHOSTS that are directly running on the
linuxaudio.org infrastructure
- allow all organizations and people that "run" one of these VHOSTS to
permanently redirect to https:// (if the choose so).

of course people who run their own VHOSTS (if any) need to implement
https:// themselves.

and of course, i'm not associated with anything linuxaudio.org, so i
don't know the exact contract under which you give away VHOSTS.

asdr
IOhannes

[Jeremy Jongepier]

Hello IOhannes,

Post by IOhannes m zmoelnig

Post by Jeremy Jongepier
Hello David,

Post by David Runge
I'm currently taking over a bunch of packages for Arch Linux (mainly
pro-audio stuff).
Would it be possible to implement letsencrypt for linuxaudio.org and all
of its subdomains?

It's possible for linuxaudio.org but not for all the subdomains. the
linuxaudio.org server is a shared server that hosts projects of a
the usage of SSL for all users, it's a decision the users have to take.

i'm not sure whether i read this correctly, but you make it sound like
there's technical problems hindering the implementation of https://,
although i think these are merely social (e.g. you don't want to shove
https:// down the throat of just anybody).

The latter, it's not a technical issue.

Post by IOhannes m zmoelnig
it's also slightly unclear what you mean by "users" (intuitively i would
have said that "users" refers to the people who want to access the
think of the 'variety of organizations and people' who host projects on
linuxaudio.org as your "users").

I mean the latter indeed, the organizations and people that use the
linuxaudio.org server are users on the server.

Post by IOhannes m zmoelnig
also, there's a slight difference between "enforcing the usage of SSL"
(shoving it down the throats of everybody) and "enabling" it.

I agree, thanks for pointing that out, had a bit too narrow of a
perspective.

Post by IOhannes m zmoelnig
https:// is a great means against mitm attacks; as ralf has pointed out,
it's less useful as a tool to ensure privacy (use tor for that) or
integrity (use gpg signatures for that). however, it does help raising
the standards for both.
there is practically no reason to *not* use https:// everywhere (well
there's one: CPU power on the server side).
- enable https:// for *all* VHOSTS that are directly running on the
linuxaudio.org infrastructure
- allow all organizations and people that "run" one of these VHOSTS to
permanently redirect to https:// (if the choose so).

CPU is not a problem. Unless anybody has any objections I'll enable SSL
for linuxaudio.org subdomains as soon as Let's Encrypt starts offering
wildcard certificates, that way we can secure more services too and it
makes maintenance a bit easier. That will be January 2018 but if LE
can't deliver in due time I'll request separate certificates. There are
some non-linuxaudio.org domains on the server too, I'll look at those too.

Post by IOhannes m zmoelnig
of course people who run their own VHOSTS (if any) need to implement
https:// themselves.
and of course, i'm not associated with anything linuxaudio.org, so i
don't know the exact contract under which you give away VHOSTS.
asdr
IOhannes

Jeremy

[David Runge]

Hey Jeremy,

thanks for getting back!

Post by Jeremy Jongepier
CPU is not a problem. Unless anybody has any objections I'll enable SSL
for linuxaudio.org subdomains as soon as Let's Encrypt starts offering
wildcard certificates, that way we can secure more services too and it
makes maintenance a bit easier. That will be January 2018 but if LE
can't deliver in due time I'll request separate certificates. There are
some non-linuxaudio.org domains on the server too, I'll look at those too.

That is good news and I'm looking forward to it!

Note, that letsencrypt certificates can easily be setup using SAN
(Subject Alternative Name), which gets around the need for a wildcard
certificate (unless you literally have hundreds of subdomains).
So that really shouldn't be a reason to wait.

Certbot indeed makes it easy to do these things, but you can of course
choose other ways to do the ACME response.

Thanks and greetings,
David

[Jeremy Jongepier]

Post by David Runge
That is good news and I'm looking forward to it!
Note, that letsencrypt certificates can easily be setup using SAN
(Subject Alternative Name), which gets around the need for a wildcard
certificate (unless you literally have hundreds of subdomains).
So that really shouldn't be a reason to wait.

All domains and subdomains that point to the linuxaudio.org server have
HTTPS enabled now. If you want a permanent redirect on a domain or
subdomain then please let me know.

Jeremy

[David Runge]

You rule!
Thanks

[Ralf Mardorf]

Post by David Runge
You rule!
Thanks

+1

But please, developers consider to sign your tarballs.

[David Runge]

Post by Ralf Mardorf
But please, developers consider to sign your tarballs.

+1

[Ralf Mardorf]

Post by IOhannes m zmoelnig
there is practically no reason to *not* use https:// everywhere

It quasi became a standard, most websites I visit are https nowadays.
We shouldn't overvalue https. I agree that it should be used, if it
shouldn't be too much effort to migrate, but again, upstream should
get used to provide signed checksums.

Post by IOhannes m zmoelnig
Yeah, more security and privacy, because Linux Audio packages are
constantly attacked by enemies :D

I don't care much about privacy when visiting Linux audio related
websites, but you shouldn't carelessly joke around regarding security.

The Jack website was successfully hacked, IIRC more than once.

[Neil C Smith]

Post by Ralf Mardorf
It quasi became a standard, most websites I visit are https nowadays.
We shouldn't overvalue https.

One reason is also that it's a de facto part of supporting HTTP/2, so these
days if you want a better performing site you also need https.

I don't care much about privacy when visiting Linux audio related

Post by Ralf Mardorf
websites, but you shouldn't carelessly joke around regarding security.

Wholeheartedly agree!

Best wishes,

Neil

Post by Ralf Mardorf
--

Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

[Janina Sajka]

Post by Jeremy Jongepier
Hello David,

Post by David Runge
I'm currently taking over a bunch of packages for Arch Linux (mainly
pro-audio stuff).
Would it be possible to implement letsencrypt for linuxaudio.org and all
of its subdomains?

It's possible for linuxaudio.org but not for all the subdomains. the
linuxaudio.org server is a shared server that hosts projects of a
the usage of SSL for all users, it's a decision the users have to take.

Well, it's quite easy, and arguably preferable, to install certs on a
domain by domain basis. This is well supported by Let's Encrypt and
certbot.

Best,

Janina

Post by Jeremy Jongepier

Post by David Runge
This would greatly improve the security of the packages hosted there (or
rather their transfer from the server to the build machine) and help for
said packages not to be dropped, as more and more distros try to switch
to more reliable and authenticatable (is that a word?) upstreams.
Additionally, there is the benefit of raising privacy for users of all
things hosted on linuxaudio.org.
An example are all sources hosted here (all of which are packages in
http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.htm

you will have to ask the owner of that subdomain if implementing HTTPS
implement it.
Jeremy
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

--
Janina Sajka, Phone: [phone]
sip:***@asterisk.rednote.net
Email: ***@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures http://www.w3.org/wai/apa

[Fons Adriaensen]

Post by Jeremy Jongepier

Post by David Runge
An example are all sources hosted here (all of which are packages in
http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.htm

you will have to ask the owner of that subdomain if implementing HTTPS
implement it.

I'm absolutely in favor of enabling https for kokkinizita.

[Janina Sajka]

As a user of Arch and various music related apps, please, please,
please!

I can report that Let's Encrypt is very easy to use. The cli tool
certbot handles things very nicely, and the docs are easy to follow.
This should not be hard to implement.

Janina

Post by David Runge
Hey all,
I'm currently taking over a bunch of packages for Arch Linux (mainly
pro-audio stuff).
Would it be possible to implement letsencrypt for linuxaudio.org and all
of its subdomains?
This would greatly improve the security of the packages hosted there (or
rather their transfer from the server to the build machine) and help for
said packages not to be dropped, as more and more distros try to switch
to more reliable and authenticatable (is that a word?) upstreams.
Additionally, there is the benefit of raising privacy for users of all
things hosted on linuxaudio.org.
An example are all sources hosted here (all of which are packages in
http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html
Best,
David
--
https://sleepmap.de
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

--
Janina Sajka, Phone: [phone]
sip:***@asterisk.rednote.net
Email: ***@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures http://www.w3.org/wai/apa

[Gordonjcp]

Post by Janina Sajka
As a user of Arch and various music related apps, please, please,
please!
I can report that Let's Encrypt is very easy to use. The cli tool
certbot handles things very nicely, and the docs are easy to follow.
This should not be hard to implement.

I'm using Let's Encrypt on https://rangerovers.pub and it's been pretty
hassle-free. I had minor issues at the start because some people were
visiting from the old domain name, but nothing insurmountable.

If you have anything where you accept user input on your website (the
obvious case being a username and password, but even a search box) then
you should absolutely be using HTTPS, right now.

[Louigi Verona]

I will joke carelessly about security all I want, sir. Why? Because jokes
are fun.

Having said that, I can vouch for the let's encrypt tool. Used it myself,
very easy to set up.

Post by Gordonjcp

Post by Janina Sajka
As a user of Arch and various music related apps, please, please,
please!
I can report that Let's Encrypt is very easy to use. The cli tool
certbot handles things very nicely, and the docs are easy to follow.
This should not be hard to implement.

I'm using Let's Encrypt on https://rangerovers.pub and it's been pretty
hassle-free. I had minor issues at the start because some people were
visiting from the old domain name, but nothing insurmountable.
If you have anything where you accept user input on your website (the
obvious case being a username and password, but even a search box) then
you should absolutely be using HTTPS, right now.
--
Gordonjcp
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev