On 04/03/2016 08:44 PM, Daniel Reurich wrote:
>

Hi there, glad we now have an actual communication channel that
everybody reads!

> SSL certificates and HSTS.
>
> HSTS should be disabled or reconfigured so that it doesn't infect all
> subdomains of devuan.org and cause browsers that have visited some
> devuan subdomains to enforce https on all devuan subdomains at the
> browser.
>

I'm sorry I put HSTS too early. I put it down the 6 months without
includeSubdomains on devuan.org so that we have a buffer for new
connections. It won't change what's already there but at least make it
easier for next changes.

> Also Let-encrypt - this is a major frustration we can't afford to wait
> around for that and have broken websites for the duration. Just buy
> some certs and look at it in years time. Not being able access to
> files.devuan.org or browse packages.devuan.org for over a week is
> terrible. My clients would fire me if I let their sites do that for a
> day!!!
>

As soon as the LE issue arised I proposed we could buy a certificate,
specifically one from Gandi as I have contacts there for a sponsorship.
The idea was to "buy it first, deal it later".

Anyway, I've been trying different things, registering files only, or
files and vagrant, the authorizations work every single time, but the
program dumps an error on on certificate generation (in testing and
production modes): Error creating new cert :: Authorizations for these
names not found or expired: -w, certs/files.devuan.org
(Acme::Client::Error::Unauthorized).

This error seems to be related to **rate limits** which should be over
_already_. I used the exact same process for other certs and it worked
fine. There are open issues at LE for reporting information about the
delay (and reason of rate limiting), but it's pending.

A global solution would be to use devuan.net or dev-1.org instead of .org.

Also, I don't have access to packages.devuan.org (46.105.191.77), so
can't do anything there.

> I'm so tempted to quit devuan because it's just so hard to get the
> necessary stuff done (due to key people not being available and not
> making sure there are others that can step in if issues arise).
>

Yes, this is an issue I hope this list can fix.

> ashamed at the state of our websites, and the state or our
> infrastructure
>

Can you be a bit more specific? I can understand the frustration at the
TLS issue, but what else?

>
> Here is a start on our core infrastructure principles which are needed
> in order to sort out the "key man" problems we are having.
>

+1 (and be responsive on gitlab issues!)

==
hk

-- 
 _ _     We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/