21 Nov
2017
21 Nov
'17
2:54 a.m.
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
--
https://sleepmap.de
21 Nov
21 Nov
6:44 a.m.
On Tue, 21 Nov 2017 02:54:14 +0100, David Runge wrote:
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.
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
10:27 a.m.
Yeah, more security and privacy, because Linux Audio packages are
constantly attacked by enemies :D
On Nov 21, 2017 06:44, "Ralf Mardorf" <ralf.mardorf(a)alice-dsl.net> wrote:
On Tue, 21 Nov 2017 02:54:14 +0100, David Runge
wrote:
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.
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
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
7:34 p.m.
On Tue, 21 Nov 2017 10:27:26 +0100, Louigi Verona wrote:
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.
26 Nov
26 Nov
4:51 p.m.
Hey Ralf,
On 2017-11-21 06:44:27 (+0100), Ralf Mardorf wrote:
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? :)
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
--
https://sleepmap.de
5:56 p.m.
On Sun, 26 Nov 2017 16:51:53 +0100, David Runge wrote:
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.
[rocketmouse@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...
[rocketmouse@archlinux ~]$ pactree -r openssl-1.0
[snip]
[rocketmouse@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
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. 
5:57 p.m.
On Sun, Nov 26, 2017 at 04:51:53PM +0100, David Runge wrote:
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,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
6:10 p.m.
On Sun, 26 Nov 2017 16:57:12 +0000, Fons Adriaensen wrote:
- 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]
[rocketmouse@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'
[rocketmouse@archlinux ~]$ grep hkp luamd64_1610.sh
key gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys FBB75451 EFE21092
--
$ 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
6:25 p.m.
On Sun, 26 Nov 2017 18:10:15 +0100, Ralf Mardorf wrote:
[rocketmouse@archlinux ~]$ grep hkp luamd64_1610.sh
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 ;).
21 Nov
21 Nov
10:49 a.m.
Hello David,
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. root(a)linuxaudio.org can't enforce
the usage of SSL for all users, it's a decision the users have to take.
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.htm
That happens to be
a subdomain root(a)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 root(a)linuxaudio.org can
implement it.
Jeremy
root(a)linuxaudio.org
11:40 a.m.
On 2017-11-21 10:49, Jeremy Jongepier wrote:
Hello David,
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 root(a)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
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. root(a)linuxaudio.org can't enforce
the usage of SSL for all users, it's a decision the users have to take.
12:44 p.m.
Hello IOhannes,
On 11/21/2017 11:39 AM, IOhannes m zmoelnig wrote:
On 2017-11-21 10:49, Jeremy Jongepier wrote:
The latter, it's not a technical issue.
Hello David,
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). 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. root(a)linuxaudio.org can't enforce
the usage of SSL for all users, it's a decision the users have to take. 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 root(a)linuxaudio.org you might
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.
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.
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).
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.
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
26 Nov
26 Nov
4:10 p.m.
Hey Jeremy,
thanks for getting back!
On 2017-11-21 12:44:41 (+0100), Jeremy Jongepier wrote:
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
--
https://sleepmap.de
10 Dec
10 Dec
9:49 p.m.
On 11/26/2017 04:10 PM, David Runge wrote:
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
10:01 p.m.
On 2017-12-10 21:57:06 (+0100), Ralf Mardorf wrote:
But please, developers consider to sign your tarballs.
+1
--
https://sleepmap.de
21 Nov
21 Nov
7:18 p.m.
On Tue, 21 Nov 2017 11:39:49 +0100, IOhannes m zmoelnig wrote:
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.
On Tue, 21 Nov 2017 10:27:26 +0100, Louigi Verona wrote:
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.
8:27 p.m.
On Tue, 21 Nov 2017, 18:19 Ralf Mardorf, <ralf.mardorf(a)alice-dsl.net> wrote:
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
websites, but you shouldn't carelessly joke around
regarding security.
Wholeheartedly agree!
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
5:03 p.m.
Jeremy Jongepier writes:
Hello David,
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
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. root(a)linuxaudio.org can't enforce
the usage of SSL for all users, it's a decision the users have to take.
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.htm
That happens to
be a subdomain root(a)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 root(a)linuxaudio.org can
implement it.
Jeremy
root(a)linuxaudio.org
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
--
Janina Sajka, Phone: +1.443.300.2200
sip:janina@asterisk.rednote.net
Email: janina(a)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
8:07 p.m.
On Tue, Nov 21, 2017 at 10:49:22AM +0100, Jeremy Jongepier wrote:
I'm absolutely in favor of enabling https for kokkinizita.
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
An example are
all sources hosted here (all of which are packages in
Arch's main repos):
http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.htm
That happens to be a subdomain root(a)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 root(a)linuxaudio.org can
implement it.
5:01 p.m.
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
David Runge writes:
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
--
https://sleepmap.de
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
--
Janina Sajka, Phone: +1.443.300.2200
sip:janina@asterisk.rednote.net
Email: janina(a)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
22 Nov
22 Nov
10:23 a.m.
On Tue, Nov 21, 2017 at 11:01:07AM -0500, Janina Sajka wrote:
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
11:12 a.m.
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.
On Nov 22, 2017 10:23, "Gordonjcp" <gordonjcp(a)gjcp.net> wrote:
On Tue, Nov 21, 2017 at 11:01:07AM -0500, Janina Sajka
wrote:
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
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
2323
days inactive
2342
days old
linux-audio-dev@lists.linuxaudio.org
23 comments
9 participants
participants (9)
-
David Runge -
Fons Adriaensen -
Gordonjcp -
IOhannes m zmoelnig -
Janina Sajka -
Jeremy Jongepier -
Louigi Verona -
Neil C Smith -
Ralf Mardorf