Re: [dev] suckless.org TLS / HTTPS support

[ilf]

hiro:
this is not about just whether something has TLS support, this is 
about giving the user choices.


If you can't speak TLS, then use gopher instead of HTTP. I hear HTTPS 
sucks, too.


--
ilf

Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung


signature.asc
Description: PGP signature

Re: [dev] suckless.org TLS / HTTPS support

[hiro]

this is not about just whether something has TLS support, this is
about giving the user choices. And the shitty TLS standard, TLS
implementations and browser interfaces are not giving people anything
remotely useful.
As I said before (and I'm repeating for everybody else, since your
dyslexia might drag them down, too), ciphers keep on changing, and
thus even if TLS 1.2 is older, the list of accepted cipher lists have
changed much more recently, and will keep on breaking things
regularly. For that http is a good fallback, especially when somebody
doesn't need your security snakeoil.

This is not your village council or democratic kindergarten parent's
advocate voting celebration. Suckless is not your crypto revolution,
all the software here should just be read completely if not already
trusted, it's small enough for that to be possible.

your arguments are the most braindead i've seen on suckless in years:
you must think that dwm sucks. I congratulate that, but i don't agree
it's because dwm doesn't deal with TLS.

> Offering HTTPS is a huge first step
No, it's mostly useless.

> But let's take another step and redirect HTTP to HTTPS. (Until it's time to 
> finally turn of HTTP.)
Just fuck off.

Thought game: If ilf's mother lacks confidentiality, authenticity and
integrity, she also opens many opportunities for downgrade scenarios.
Does that make her evil?

Your logic is more hurtful than trying to swallow a whole thinkpad,
opened up 180 degrees.

On 8/31/17, ilf  wrote:
> Paul Menzel:
>> I understood it the way, that there might be programs not being able
>> to deal with TLS.
>
> The first version of SSL/TLS became a standard in 1999. TLS 1.2 is from
> 2008, over nine years ago: https://tools.ietf.org/html/rfc5246
>
> Any software that can't deal with TLS is IMHO broken - and sucks.
>
> Really, cleartext is evil for many reasons: it lacks confidentiality,
> authenticity and integrity - and it opens many opportunities for
> downgrade scenarios.
>
> The Snowden relevations have shown that the internet is under attack and
> technologists should actively work against that:
>
> Pervasive Monitoring Is an Attack
> https://tools.ietf.org/html/rfc7258
>
> Confidentiality in the Face of Pervasive Surveillance
> https://tools.ietf.org/html/rfc7624
>
> So please, let's try to move away from cleartext to encrypted
> connections. Offering HTTPS is a huge first step. But let's take another
> step and redirect HTTP to HTTPS. (Until it's time to finally turn of
> HTTP.)
>
> Thanks.
>
> --
> ilf
>
> Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
>   -- Eine Initiative des Bundesamtes für Tastaturbenutzung
>

Re: [dev] suckless.org TLS / HTTPS support

[ilf]

Paul Menzel:
I understood it the way, that there might be programs not being able 
to deal with TLS.


The first version of SSL/TLS became a standard in 1999. TLS 1.2 is from 
2008, over nine years ago: https://tools.ietf.org/html/rfc5246


Any software that can't deal with TLS is IMHO broken - and sucks.

Really, cleartext is evil for many reasons: it lacks confidentiality, 
authenticity and integrity - and it opens many opportunities for 
downgrade scenarios.


The Snowden relevations have shown that the internet is under attack and 
technologists should actively work against that:


Pervasive Monitoring Is an Attack
https://tools.ietf.org/html/rfc7258

Confidentiality in the Face of Pervasive Surveillance
https://tools.ietf.org/html/rfc7624

So please, let's try to move away from cleartext to encrypted 
connections. Offering HTTPS is a huge first step. But let's take another 
step and redirect HTTP to HTTPS. (Until it's time to finally turn of 
HTTP.)


Thanks.

--
ilf

Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung


signature.asc
Description: PGP signature

Re: [dev] Writing subtitles for videos

[hiro]

no, please don't contribute to suckless, your code will suck like usual.

Re: [dev] suckless.org TLS / HTTPS support

[hiro]

Another funny little detail: You want elitism and require all users to
change/write/contribute C code, but then you think they are too dumb
to realize that they shouldn't 100% trust a http connection?
You think somebody at this level is too dumb to just type the https in
front if they really care about the level of security you're trying to
promote here?

Re: [dev] suckless.org TLS / HTTPS support

[hiro]

> Clients who do not wish to connect via HTTPS but HTTP can just ignore
> the STS-header, but browsers who can could expose a configuration
> setting for the user to determine how to behave when being confronted
> with a HSTS-header in an HTTP-context.
>
> This would completely rid us from the need for extensions like "HTTPS
> Everywhere" and we would still keep HTTPS optional.

With HTTPS Everywhere *the user* gets to decide when to use https.
With all http based solutions anybody between you and the legit server
will decide whether you get to use https or not.

Re: [dev] suckless.org TLS / HTTPS support

[hiro]

> These are 2 different issues and HTTP redirection is optional.

Something being optional does not prevent it from having net negative effect.

> Renewing certificates is much easier with LetsEncrypt. All subdomains of
> suckless are known. There are too many subdomains though imho.

Nobody can remember all the subdomains, and each has to be renewed
manually. That makes it too much work, and I guess if it wasn't too
much work garbeam could have just done it himself, so that people
depending on the security promised by your silly certs only have to
trust the integrity and competence of one person.

I don't think the subdomains or it's number should be changed,
anything like this is just gonna break links anywhere else. The net
negative effect on the community is not worth it and the
suckless/dwm/wmii community has already suffered enough negative
reputation from shit like this.

> Wildcard implementations can be a security risk since they are more
> complicated.
> An example was a wildcard certificate that is NUL terminated and some CA's
> and
> browsers accepted a wildcard for ALL domains (in a nutshell).

Browsers and SSL implementations were always broken, that doesn't make
wildcards automatically bad. The NULL issue was bad enough without the
wildcard problem.
The real problem here is just kindergarten programming, and your
argument reminds me of the usual boring goto is bad, type safety,
training wheels rhetoric.
If you were consistent in any way you'd just tell us not to use SSL,
there are s many deep flaws in the stupid libraries, it's
completely hopeless.

> Though LetsEncrypt announced it will likely support wildcard domains in
> Januari 2018.
> https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html

That's great. Meanwhile everybody will have to delete their
subdomains, use paid-for certs or waste their time creating temporary
technical solutions for automatic handling of the subdomains that are
not supported by the incompetent letsencrypt people when they would be
needed by potential users like you guys...

>> Instead of having to trust garbeam I now have to trust third persons
>> (i can't even count them), because it's too much work for garbeam to
>> just make a certificate that my browser will think is ok.
>>
>
> That's bullshit, the difference is the certificate is signed by a CA. It's
> up
> to you to decide to trust and use it anyway.
>

I trust the CA (even the incompetent letsencrypt people) more than
some random mailing list user that garbeam decided to trust.
At least I understand the general process of an inefficient useless
company that letsencrypt is, and I know they can't efficiently harm me
and all their other users in the same way suckless user will for sure
do, and has done in the past (i don't mean compromises of security,
but in effect making web sites completely inaccessible by their small
communities).

Most people that you're trying to help stay secure probably know
garbeam and the others *even less* than me, so if they have to
suddenly start trusting so many more random people to get any small
security advantage, what should make them bother in the first place?
Are you not just again completely relying on the browser distributors
to decide what is right and important for the users instead of taking
things in your own hands and making a difference as suckless in the
webshit world? To me any engagement in this stuff is not just passive
acceptance, it's active increase of suck.

>> That's why I wonder why you have put all this effort to begin with.
>> Who are you trying to protect who isn't already gonna use the Ubuntu
>> pgp-signed packages?
>
> The Ubuntu package maintainers have to fetch the sources in a trusted way.
> I
> agree this is not solved with HTTPS.
> That's why the sources could be PGP signed aswell (just an idea atm).

Can they not just use the ssh access then? You could allow them to
verify your ssh public key in a multitude of ways that are more secure
than using ssl and honest achmed CAs.

>> The people who manage to write code and compile
>> it and contribute back who already have the sshd public key trusted in
>> their .ssh folder?
>>
>
> Yes, but thats the minority unfortunately.
>
> As usual you're not offering any solutions. But you were more constructive
> than
> usual. Are you feeling well, hiro?

It's just that there's more stupid shit done here lately, so it
overlaps with my ranting realms.

Re: [dev] Opinions on GNU stow

[Matthew Parnell]

Hi  fao_,

> what is suckless' general opinion of GNU Stow. [...] I am asking your
> opinions on the general concept and how it has been implemented.
> Specifically, the idea of installing under a 'package' directory, and
> symlinking from there to the proper install location.

As with many here, I do disagree to use it as a primary package manage ,
solutionand we all know the issues with multiple package management s.

I do use GNU Stow myself; however, only as a tool to provide a nice
wrapper to link my dotfiles from a git repo to where they ought to be.

I must admit, I have used GNU Stow for something like a package
management solution; a cluster which I have no admin privileges, but
full permissions in one of the shared directory structures; and am
required to maintain a separate environment for all those who use it...
not ideal.

I do not believe there's anything necessarily wrong with the concept
of using GNU Stow for a nice wrapper around symlinking, for specific
purposes, such as dotfile management etc.

In fact, I was thinking of writing a GNU Stow drop in replacement in
Suckless-style C when I find some time (GNU Stow is written in Perl, I
believe).

-- 
Matthew Parnell
m...@parnmatt.co.uk

Re: [dev] Opinions on GNU stow

[hiro]

what makes you think the complexity of trying to replace symlinks with
something slightly less sucky is worth the gain?

is it all just about perceived cleanliness or is there also a
practical advantage?

tinycorelinux packages are "extreme"? why?

On 8/31/17, Anselm R Garbe  wrote:
> On 31 August 2017 at 09:33, hiro <23h...@gmail.com> wrote:
>> The reason symlinks are still being used is that unions on linux are
>> an even bigger, unstable piece of shit. The tinycorelinux people tried
>> them out for their package system and had to give up and use the
>> "hack" instead.
>
> See my other mail, I wouldn't take it into the extreme, but just
> define a couple of use-case specific "overlays".
>
> Old school package managers would become part of contributing into an
> overlay repo that consists of a full range of tools
> sharing/contributing to a common use case.
>
> BR,
> Anselm
>
>

Re: [dev] Writing subtitles for videos

[Quentin Rameau]

> I think you mean "I am really glad".

No, you're wrong.

> It sounds like you want to have a discussion about how to do things
> constructively.

Not really, I just do things, discussions are what you do and this is
certainly not constructive, as we can see here.

> Are you sure you would have anything to contribute to such a
> discussion, or are you just going to give me a four paragraph feature
> request without actually contributing anything yourself?

I'm sorry, I don't usually contribute to such discussions, I contribute
to actual projects with actual code.
People like you contribute to feature requests and useless discussions,
and noise.

> No, please, the thanks must go to *you*, for adding noise to call me
> out on making noise about you making noise.

I never called you, I don't even know you, you came on your own with
your bro thing (not sure what this is).

> Noise ad infinitum

No, let's stop here, I think too much time has already been wasted (at
least mine for sure).
Feel free to add something surely most useful to this thread, although
I'd prefer you'd actually contribute to suckless, you can find a lot of
things needing actual work to be done.

Re: [dev] Linking a directory tree of configuration files

[Truls Becken]

On 2017-08-31 09:19, Thomas Levine wrote:
> it would be acceptable to have something like cp -R that differed
> only in that it made hard links instead of copies

This sentence stood out to me because cp already does that with
the -l switch.

Re: [dev] suckless.org TLS / HTTPS support

[Anselm R Garbe]

On 31 August 2017 at 15:36, Hiltjo Posthuma  wrote:
> On Thu, Aug 31, 2017 at 03:07:11PM +0200, Anselm R Garbe wrote:
>> well ;)), but I'm also a sceptic of HSTS.
>
> Can you explain why you are a sceptic of HSTS?

I'm sceptic of using HSTS on suckless.org. I think it is superfluous.

I really prefer that website visitors perform a *conscious* transition
to https urls of suckless.org (after learning about it in our news
feed that you wrote) rather than mandating the browser (which might
support HSTS) to perform some kind of a "magic" transition instead.
Actually the user might not notice at all if his browser supports
HSTS.

It's kind of an infantilization of the user.

Also I dislike the idea that browsers effectively share HSTS
information gathered in regular mode even in private (aka incognito)
mode (at least I read about this last time I looked into HSTS, which
is a while back).

BR,
Anselm

Re: [dev] suckless.org TLS / HTTPS support

[Laslo Hunhold]

On Thu, 31 Aug 2017 15:36:03 +0200
Hiltjo Posthuma  wrote:

Dear Hiltjo,

> There is no issue (anymore) because I fixed the main template.
> An example is the logo.svg had a direct http:// link. This gives a
> "mixed content" warning in your browser. A MITM can abuse plain-text
> traffic, this is not possible by specifying a HSTS header. Ofcourse
> the person has to first make a single HTTPS request with the HSTS
> header set. After that it works (until the expiration date, which is
> set to 1 year atm).

what makes me wonder is why the HSTS-spec tells conformant clients to
ignore the STS-header in the context of a HTTP connection, given this
would be a perfect way to implement an "offering" of a TLS-connection
to a browser.
Clients who do not wish to connect via HTTPS but HTTP can just ignore
the STS-header, but browsers who can could expose a configuration
setting for the user to determine how to behave when being confronted
with a HSTS-header in an HTTP-context.

This would completely rid us from the need for extensions like "HTTPS
Everywhere" and we would still keep HTTPS optional.

With best regards

Laslo Hunhold

-- 
Laslo Hunhold 

Re: [dev] suckless.org TLS / HTTPS support

[Hiltjo Posthuma]

On Thu, Aug 31, 2017 at 03:07:11PM +0200, Anselm R Garbe wrote:
> On 31 August 2017 at 14:45, hiro <23h...@gmail.com> wrote:
> > Now we have something much worse: letsencrypt and this completely
> > insecure http redirection snake-oil.
> >
> > With letsencrypt you now have to put extra work (can't keep track of
> > all the individual subdomains either, wildcards are suddenly a
> > security risk?!), and nobody bothers to quanitfy the amount of gained
> > security.
> 
> I don't really mind letsencrypt (actually I wouldn't mind to make a
> deal with HonestAchmed or his cousin -- we can all trust them, because
> the uncle of a friend is his step brother and knows the family very
> well ;)), but I'm also a sceptic of HSTS.
> 

Can you explain why you are a sceptic of HSTS?

> Where do we really have a downgrade risk? In the content suckless
> offers, this can be solved by using relative or non-protocol hrefs
> everywhere. I wouldn't mind if existing external links are not
> redirected, during time external references will adopt slowly.
> 
> BR,
> Anselm
> 

There is no issue (anymore) because I fixed the main template.
An example is the logo.svg had a direct http:// link. This gives a
"mixed content" warning in your browser. A MITM can abuse plain-text
traffic, this is not possible by specifying a HSTS header. Ofcourse
the person has to first make a single HTTPS request with the HSTS header
set. After that it works (until the expiration date, which is set to
1 year atm).

-- 
Kind regards,
Hiltjo

Re: [dev] suckless.org TLS / HTTPS support

[Hiltjo Posthuma]

On Thu, Aug 31, 2017 at 02:45:03PM +0200, hiro wrote:
> > I agree or just a simple HTTPs browser bookmark. I think thats better on
> > many
> > levels, for example otherwise someone can also spoof a plain HTTP redirect.
> 
> Browser distributors had the chance to implement something like this,
> plus client side certificate pinning, but they fucked it up.
> 

I agree, still I think its a good thing to provide TLS optionally. Another
idea would be to also add support for Tor hidden services, this is trivial to
add.

> Now we have something much worse: letsencrypt and this completely
> insecure http redirection snake-oil.
> 

These are 2 different issues and HTTP redirection is optional.

> With letsencrypt you now have to put extra work (can't keep track of
> all the individual subdomains either, wildcards are suddenly a
> security risk?!), and nobody bothers to quanitfy the amount of gained
> security.
> 

Renewing certificates is much easier with LetsEncrypt. All subdomains of
suckless are known. There are too many subdomains though imho.

Wildcard implementations can be a security risk since they are more complicated.
An example was a wildcard certificate that is NUL terminated and some CA's and
browsers accepted a wildcard for ALL domains (in a nutshell).

See the legendary talk:

More Tricks For Defeating SSL
by Moxie Marlinspike

https://www.blackhat.com/html/bh-usa-09/bh-usa-09-archives.html#Marlinspike

Though LetsEncrypt announced it will likely support wildcard domains in Januari 
2018.
https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html

> Instead of having to trust garbeam I now have to trust third persons
> (i can't even count them), because it's too much work for garbeam to
> just make a certificate that my browser will think is ok.
> 

That's bullshit, the difference is the certificate is signed by a CA. It's up
to you to decide to trust and use it anyway.

> That's why I wonder why you have put all this effort to begin with.
> Who are you trying to protect who isn't already gonna use the Ubuntu
> pgp-signed packages?

The Ubuntu package maintainers have to fetch the sources in a trusted way. I
agree this is not solved with HTTPS.
That's why the sources could be PGP signed aswell (just an idea atm).

> The people who manage to write code and compile
> it and contribute back who already have the sshd public key trusted in
> their .ssh folder?
> 

Yes, but thats the minority unfortunately.

As usual you're not offering any solutions. But you were more constructive than
usual. Are you feeling well, hiro?

-- 
Kind regards,
Hiltjo

Re: [dev] Linking a directory tree of configuration files

[fao_]

On 2017-08-31 8:19 am, Thomas Levine wrote:

Having trouble installing rcm on some computers, I came up with the
following alternative a couple weeks ago. I have been pleased.
https://thomaslevine.com/scm/lntree/
https://thomaslevine.com/scm/lntree/uv/lntree-0.1.tar.gz

Here is an example of where I have used it to compose configurations.
https://thomaslevine.com/scm/os/artifact?ln=17..25=fb261310832d4eb6

Does something else like this exist? I could do without some of the
features; for example, it would be acceptable to have something like
cp -R that differed only in that it made hard links instead of copies.



GNU stow? :D

I jest.

--
- fao_
PGP fingerprint: 739B 6C5C 3DE1 33FA
"Too enough is always not much!"

Re: [dev] Writing subtitles for videos

[Timothy Rice]

> We are really glad to know you've been entertained.

I think you mean "I am really glad".


> this would have been more constructive to address directly Thomas to ask
> about his needs if you're interested at all in this discussion.

It sounds like you want to have a discussion about how to do things
constructively.

Are you sure you would have anything to contribute to such a discussion, or
are you just going to give me a four paragraph feature request without
actually contributing anything yourself?


> Thank you for the noise, bro.

No, please, the thanks must go to *you*, for adding noise to call me out on
making noise about you making noise.

Noise ad infinitum, all because you called out isabella for calling out
Thomas for presenting a four paragraph feature request.

Your bat.

Re: [dev] suckless.org TLS / HTTPS support

[Anselm R Garbe]

On 31 August 2017 at 14:45, hiro <23h...@gmail.com> wrote:
> Now we have something much worse: letsencrypt and this completely
> insecure http redirection snake-oil.
>
> With letsencrypt you now have to put extra work (can't keep track of
> all the individual subdomains either, wildcards are suddenly a
> security risk?!), and nobody bothers to quanitfy the amount of gained
> security.

I don't really mind letsencrypt (actually I wouldn't mind to make a
deal with HonestAchmed or his cousin -- we can all trust them, because
the uncle of a friend is his step brother and knows the family very
well ;)), but I'm also a sceptic of HSTS.

Where do we really have a downgrade risk? In the content suckless
offers, this can be solved by using relative or non-protocol hrefs
everywhere. I wouldn't mind if existing external links are not
redirected, during time external references will adopt slowly.

BR,
Anselm

Re: [dev] suckless.org TLS / HTTPS support

[hiro]

> I agree or just a simple HTTPs browser bookmark. I think thats better on
> many
> levels, for example otherwise someone can also spoof a plain HTTP redirect.

Browser distributors had the chance to implement something like this,
plus client side certificate pinning, but they fucked it up.

Now we have something much worse: letsencrypt and this completely
insecure http redirection snake-oil.

With letsencrypt you now have to put extra work (can't keep track of
all the individual subdomains either, wildcards are suddenly a
security risk?!), and nobody bothers to quanitfy the amount of gained
security.

Instead of having to trust garbeam I now have to trust third persons
(i can't even count them), because it's too much work for garbeam to
just make a certificate that my browser will think is ok.

That's why I wonder why you have put all this effort to begin with.
Who are you trying to protect who isn't already gonna use the Ubuntu
pgp-signed packages? The people who manage to write code and compile
it and contribute back who already have the sshd public key trusted in
their .ssh folder?

For yourself you anyway lack of any meaningful all-encompassing
security strategy. Cause secretly you know the risk is small, or many
other, unrelated, but more important risks in life are bigger and
demand for more of your attention. If you live in Europe you probably
won't even be able to supply enough ammo for self-defense of your
source-code.

Re: [dev] Writing subtitles for videos

[Quentin Rameau]

> Unlike the OP's four paragraph feature request against software which
> suckless obviously doesn't offer, I have at least found isabella's
> content entertaining and concise.

We are really glad to know you've been entertained.

> While I'm sure it was kind of you to step in to defend your bro, I
> would have preferred if your bro had demonstrated the simple ability
> to report what they found unsatisfactory about existing software and
> provided their first stab at some C code aimed at addressing the
> perceived problems.

I don't know Thomas more than I know you (ie not at all).
But I know Izabera.

While it's kind of you to step in to defend your bro, this would have
been more constructive to address directly Thomas to ask about his
needs if you're interested at all in this discussion.

Thank you for the noise, bro.

Re: [dev] suckless.org TLS / HTTPS support

[hiro]

> Some privacy-settings clean all states on exit, including cookes and
> HSTS.

You have to make a trade-off here anyway. You can't have perfection at no costs.

And if Eve controls the path between Adam and suckless it simply won't
allow a redirection to https.
There's no significant added security.

Re: [dev] suckless.org TLS / HTTPS support

[Hiltjo Posthuma]

On Thu, Aug 31, 2017 at 11:42:51AM +0200, Paul Menzel wrote:
> Dear suckless folks,
> 
> 
> On 08/31/17 11:36, ilf wrote:
> > Hiltjo Posthuma:
> > > I'm not a fan of automatic http to HTTPs redirects. It would break
> > > support for some text-based clients or some simple scripts as an
> > > example.
> > 
> > I'm a huge fan of these redirects. A simple 301 Moved Permanently has
> > been part of RFC 2616 sinde 1999 and anything not able to handle that is
> > broken: https://tools.ietf.org/html/rfc2616#section-10.3.2
> > 
> > Can you tell which clients and scripts break and how?
> 
> I understood it the way, that there might be programs not being able to deal
> with TLS.
> 

Indeed thats what I meant.

> > > HSTS support makes sure http to https links are changed on the
> > > client-side.
> > 
> > Some privacy-settings clean all states on exit, including cookes and
> > HSTS. And people mostly type domains into an URL bar, not protocols.
> 
> Two more options would be DNSSEC/DANE for the Web service [1] and HTTPS
> Everywhere [2].
> 

I agree or just a simple HTTPs browser bookmark. I think thats better on many
levels, for example otherwise someone can also spoof a plain HTTP redirect.

-- 
Kind regards,
Hiltjo

Re: [dev] suckless.org TLS / HTTPS support

[hiro]

> Can you tell which clients and scripts break and how?

Any client.
Ciphers keep on changing, and whenever you use an older SSL
implementation anywhere, even if you specifically don't need the level
of security you nerds have declared necessary, there might be no way
to access the content at all.

Re: [dev] Opinions on GNU stow

[Anselm R Garbe]

On 31 August 2017 at 09:33, hiro <23h...@gmail.com> wrote:
> The reason symlinks are still being used is that unions on linux are
> an even bigger, unstable piece of shit. The tinycorelinux people tried
> them out for their package system and had to give up and use the
> "hack" instead.

See my other mail, I wouldn't take it into the extreme, but just
define a couple of use-case specific "overlays".

Old school package managers would become part of contributing into an
overlay repo that consists of a full range of tools
sharing/contributing to a common use case.

BR,
Anselm

Re: [dev] suckless.org TLS / HTTPS support

[hiro]

> Thanks for all the work!

Same, please keep it up.

Re: [dev] Writing subtitles for videos

[hiro]

> i thought this was a mailing list for hackers?

hahahahahahahaha

Re: [dev] Writing subtitles for videos

[hiro]

> i judge people by their ability to perform basic tasks
define basic.

Re: [dev] Writing subtitles for videos

[hiro]

> i'm fairly confident my grandma could do it too
> maybe she can teach you for a small fee

i'm glad she taught you these very important life skills. i'm sure it
will come in handy when you can install an arschlinux for some
desperate hooker in return for food and LTE traffic.

Re: [dev] Writing subtitles for videos

[hiro]

finally somebody with a legit software requirement! nobody cares about
a nerd's imagined answers to imagined problems.
thanks kamil, it was about time somebody contributed something of
actual value on this list. :)

Re: [dev] Writing subtitles for videos

[Kamil Cholewiński]

Background: a close friend is doing subtitling for $, usually for local
film festivals. One festival often means dozens of movies to be
translated and subtitled. Most people doing this are freelance
translators with limited technical background.

> ffplay prints the playback time in centisecond precision to the terminal
> when it is playing, so you can pause to see where in the video you are
> and write the time down yourself.

No, this is beyond stupid. Try this when you have dozens of hours of
video to subtitle, on a deadline. You want this activity to be as
streamlined as humanly possible. There's no room for philosophy here,
the people doing this are already tired.

The current de-facto state of the art is to hit a key to show-next/hide
the subtitle while the video is playing. This can be done live while the
film is being displayed at a theater, or pre-recorded (possibly with
time-stretched playback).

> I haven't editted a lot of subtitles, but for sound synchronization, a
> waveform is extremely useful.

Now this is an interesting idea and I think extending existing software
with this functionality would make it somewhat more usable.

Any improvement that takes away a part of the manual labor would be
awesome. Using machine learning, or speech recognition, to auto-suggest
subtitle timing? Hell fucking yeah, that would seriously rock.

<3,K.

Re: [dev] Writing subtitles for videos

[Thomas Levine]

As Felix pointed out (and I had not previously realized), the subtitles
depend mostly on the audio, and the video can largely be ignored.
I thus think it has relatively little to do with blind.

I had looked at mpv and came upon the annoyingly close but still
unhelpful watch-later feature. I considered whether it was possible to
implementing my proposal with just edits to input.conf and whether it
was worth using libmpv, but had not considered lua scripts. A Lua script
indeed looks promising.
https://gist.github.com/Hakkin/5489e511bd6c8068a0fc09304c9c5a82
https://github.com/thebombzen/scripts/blob/master/src/markchapter.lua

It still seems a bit messy, (Perhaps a scripting language could be
avoided entirely if the mpv configuration were written in C.) but this
will probably satisfy me for now.

Re: [dev] Writing subtitles for videos

[Hadrien Lacour]

On Thu, Aug 31, 2017 at 08:04:26AM +, Thomas Levine wrote:
> I want to write some subtitles for some videos. I found several subtitle
> editors through web searches, and their documentation doesn't make them
> look very good. What's more, I haven't managed to install any of them
> properly, which is both inconvenient and further indicative of suck.
>
> I think that most of what I want could be accomplished by having a video
> player that writes the current time somewhere (like a file) when I press
> a particular key. I would play the video until I get to the position
> where I want to start or stop a subtitle, then I would press the key,
> and then I would copy that time to the subtitles file.
>
> Another helpful feature would be to reload the subtitles file without
> changing the current time; this way I could review the subtitles more
> quickly.
>
> Do any video players already do this? Or, does anyone have other
> recommendations about the editing of subtitles?
>

It may be possible to do this with mpv and lua scripts.

Re: [dev] Writing subtitles for videos

[isabella parakiss]

On 8/31/17, Quentin Rameau  wrote:
>> i judge people by their ability to perform basic tasks
>
> Like trolling on mailing lists, thank you.
>
>


https://asciinema.org/a/uxviYMKZbD1FJ2ftRKUo5lVj8
i thought this was a mailing list for hackers?
am i the troll or the guy that can't do this?

Re: [dev] Writing subtitles for videos

[Mattias Andrée]

On Thu, 31 Aug 2017 11:34:00 +0200
Quentin Rameau  wrote:

> Hi Mattias
> 
> > I tried it out, it sucked donkey balls; i'd rather just use
> > ffplay and a text editor; the video playback didn't even work
> > for me.  
> 
> Isn't this something that could be done with blind?
> I wonder if this would be within its goal scope.
> 

I'm not planing to do subtitles, I want to keep it purely
video. However, it's in the todo-list to make a simple
graphical tool for finding frames. It will have video and
audio playback, keyframe listing, and maybe waveforms, as
well as timestamp and frame number. So it will be useful
as an alternative to the ffplay part.

Re: [dev] Writing subtitles for videos

[Quentin Rameau]

> i judge people by their ability to perform basic tasks

Like trolling on mailing lists, thank you.

Re: [dev] Writing subtitles for videos

[isabella parakiss]

On 8/31/17, Quentin Rameau  wrote:
>> 99% of the fansubbers use aegisub
>> they're teens and they all managed to install it properly
>> i'm fairly confident my grandma could do it too
>> maybe she can teach you for a small fee
>
> We're glad to know you judge the quality of a software by its ability
> te be easily installed only.
>
>


i judge people by their ability to perform basic tasks

Re: [dev] suckless.org TLS / HTTPS support

[Paul Menzel]

Dear suckless folks,


On 08/31/17 11:36, ilf wrote:

Hiltjo Posthuma:
I'm not a fan of automatic http to HTTPs redirects. It would break 
support for some text-based clients or some simple scripts as an example.


I'm a huge fan of these redirects. A simple 301 Moved Permanently has 
been part of RFC 2616 sinde 1999 and anything not able to handle that is 
broken: https://tools.ietf.org/html/rfc2616#section-10.3.2


Can you tell which clients and scripts break and how?


I understood it the way, that there might be programs not being able to 
deal with TLS.


HSTS support makes sure http to https links are changed on the 
client-side.


Some privacy-settings clean all states on exit, including cookes and 
HSTS. And people mostly type domains into an URL bar, not protocols.


Two more options would be DNSSEC/DANE for the Web service [1] and HTTPS 
Everywhere [2].



Kind regards,

Paul


[1] 
https://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec

[2] https://www.eff.org/de/https-everywhere

Re: [dev] suckless.org TLS / HTTPS support

[ilf]

Hiltjo Posthuma:
I'm not a fan of automatic http to HTTPs redirects. It would break 
support for some text-based clients or some simple scripts as an 
example.


I'm a huge fan of these redirects. A simple 301 Moved Permanently has 
been part of RFC 2616 sinde 1999 and anything not able to handle that is 
broken: https://tools.ietf.org/html/rfc2616#section-10.3.2


Can you tell which clients and scripts break and how?

HSTS support makes sure http to https links are changed on the 
client-side.


Some privacy-settings clean all states on exit, including cookes and 
HSTS. And people mostly type domains into an URL bar, not protocols.


--
ilf

Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung


signature.asc
Description: PGP signature

Re: [dev] Writing subtitles for videos

[Quentin Rameau]

Hi Mattias

> I tried it out, it sucked donkey balls; i'd rather just use
> ffplay and a text editor; the video playback didn't even work
> for me.

Isn't this something that could be done with blind?
I wonder if this would be within its goal scope.

Re: [dev] Writing subtitles for videos

[Mattias Andrée]

On Thu, 31 Aug 2017 11:25:21 +0200
Quentin Rameau  wrote:

> > 99% of the fansubbers use aegisub
> > they're teens and they all managed to install it properly
> > i'm fairly confident my grandma could do it too
> > maybe she can teach you for a small fee  
> 
> We're glad to know you judge the quality of a software by its ability
> te be easily installed only.
> 

I tried it out, it sucked donkey balls; i'd rather just use
ffplay and a text editor; the video playback didn't even work
for me.


pgpy3TR9Nl7ij.pgp
Description: OpenPGP digital signature

Re: [dev] Writing subtitles for videos

[Quentin Rameau]

> 99% of the fansubbers use aegisub
> they're teens and they all managed to install it properly
> i'm fairly confident my grandma could do it too
> maybe she can teach you for a small fee

We're glad to know you judge the quality of a software by its ability
te be easily installed only.

Re: [dev] suckless.org TLS / HTTPS support

[Hiltjo Posthuma]

yOn Thu, Aug 31, 2017 at 10:02:43AM +0200, ilf wrote:
> Hiltjo Posthuma:
> > suckless.org now supports TLS using LetsEncrypt.
> 
> Awesome, thanks a lot!
> 
> Any chance to implement permanent redirects from http to https?
> 
> -- 
> ilf
> 
> Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
>   -- Eine Initiative des Bundesamtes für Tastaturbenutzung

Thanks,

I'm not a fan of automatic http to HTTPs redirects. It would break support for
some text-based clients or some simple scripts as an example. HSTS support makes
sure http to https links are changed on the client-side. Using a bookmark to the
https version of suckless then fixes it. But I'd like to hear more opinions 
about
this, it can be changed.

Absolute links (if needed) on the wiki page can be rewritten to the standard 
form,
for example: http://git.suckless.org/ to //git.suckless.org/ then it uses the
current protocol scheme to connect and it works for both http and https.
Ofcourse using relative paths are recommended.

An exception to this rule is if a page specifies:

git clone http://git.suckless.org/project

then it should be:

git clone https://git.suckless.org/project

-- 
Kind regards,
Hiltjo


signature.asc
Description: PGP signature

Re: [dev] Writing subtitles for videos

[isabella parakiss]

On 8/31/17, Thomas Levine <_...@thomaslevine.com> wrote:
> I want to write some subtitles for some videos. I found several subtitle
> editors through web searches, and their documentation doesn't make them
> look very good. What's more, I haven't managed to install any of them
> properly, which is both inconvenient and further indicative of suck.


99% of the fansubbers use aegisub
they're teens and they all managed to install it properly
i'm fairly confident my grandma could do it too
maybe she can teach you for a small fee

Re: [dev] Writing subtitles for videos

[Mattias Andrée]

On Thu, 31 Aug 2017 08:04:26 +
Thomas Levine <_...@thomaslevine.com> wrote:

> I want to write some subtitles for some videos. I found several subtitle
> editors through web searches, and their documentation doesn't make them
> look very good. What's more, I haven't managed to install any of them
> properly, which is both inconvenient and further indicative of suck.
> 
> I think that most of what I want could be accomplished by having a video
> player that writes the current time somewhere (like a file) when I press
> a particular key. I would play the video until I get to the position
> where I want to start or stop a subtitle, then I would press the key,
> and then I would copy that time to the subtitles file.
> 
> Another helpful feature would be to reload the subtitles file without
> changing the current time; this way I could review the subtitles more
> quickly.
> 
> Do any video players already do this? Or, does anyone have other
> recommendations about the editing of subtitles?
> 

ffplay prints the playback time in centisecond precision to the terminal
when it is playing, so you can pause to see where in the video you are
and write the time down yourself.


pgpsRhwM6jLv5.pgp
Description: OpenPGP digital signature

Re: [dev] Writing subtitles for videos

[Felix Van der Jeugt]

Hi

Quoting Thomas Levine (2017-08-31 10:04:26)
> Or, does anyone have other recommendations about the editing of
> subtitles?

I haven't editted a lot of subtitles, but for sound synchronization, a
waveform is extremely useful. Instead of hitting a button when you hear
something, you can just select the exact point the amplitude increases.

I'm afraid I don't know any even remotely suckless tools for this,
though.

Sincerely,
Felix



signature.asc
Description: signature

Re: [dev] suckless.org TLS / HTTPS support

[Anselm R Garbe]

Hi Hiltjo,

On 30 August 2017 at 23:06, Hiltjo Posthuma  wrote:
> suckless.org now supports TLS using LetsEncrypt. Cloning git repos over HTTPS
> works now. Some links on the page have been changed to allow both HTTP and
> HTTPS.
>
> HSTS is not fully working yet. This will be fixed.
>
> The IPv6  record was added and IPv6 is fully working now.
>
> suckless has many subdomains, these should hopefully all work via TLS. If you
> see a subdomain without a signed certificate please report it. If you find any
> broken links on the wiki pages, these can be fixed by anyone.

Excellent, thank you for your effort with the certificates.

BR,
Anselm

[dev] Writing subtitles for videos

[Thomas Levine]

I want to write some subtitles for some videos. I found several subtitle
editors through web searches, and their documentation doesn't make them
look very good. What's more, I haven't managed to install any of them
properly, which is both inconvenient and further indicative of suck.

I think that most of what I want could be accomplished by having a video
player that writes the current time somewhere (like a file) when I press
a particular key. I would play the video until I get to the position
where I want to start or stop a subtitle, then I would press the key,
and then I would copy that time to the subtitles file.

Another helpful feature would be to reload the subtitles file without
changing the current time; this way I could review the subtitles more
quickly.

Do any video players already do this? Or, does anyone have other
recommendations about the editing of subtitles?

Re: [dev] suckless.org TLS / HTTPS support

[ilf]

Hiltjo Posthuma:

suckless.org now supports TLS using LetsEncrypt.


Awesome, thanks a lot!

Any chance to implement permanent redirects from http to https?

--
ilf

Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung


signature.asc
Description: PGP signature

Re: [dev] suckless.org TLS / HTTPS support

[Silvan Jegen]

On Wed, Aug 30, 2017 at 11:06 PM, Hiltjo Posthuma
 wrote:
> suckless.org now supports TLS using LetsEncrypt. Cloning git repos over HTTPS
> works now. Some links on the page have been changed to allow both HTTP and
> HTTPS.

Thanks for all the work!


Cheers,

Silvan

Re: [dev] Opinions on GNU stow

[hiro]

> Symlinks have always been a hack due to Unix' lack of a proper
> namespaces approach. Plan 9 later fixed this by introducting a proper
> namespaces approach[1] - but even today unices (incl. Linux) have
> almost ignored the learnings of Plan 9 with some exceptions.

Yes, they are a hack, but linux will never be plan9, so I'll keep on
using them to approximate the plan9 binds.

Plan9 binds are also not very nice in practice with all the open and
walks not being done efficiently. A lot of roundtrips are wasted, so
there is potential, but nobody did the work yet. Till then symlinks
are at least performant.

> In terms of a packaging manager, I'm a proponent of the idea I
> introduced with stali as well. It does not require a package
> "manager", but uses git for the rootfs overlay instead. If you want a
> certain version of the system, you check out the required version from
> /.git.

9front practice agrees with this point. I really like the resulting experience.

> openoffice etc. I would try to adopt union mounting overlays into some

The reason symlinks are still being used is that unions on linux are
an even bigger, unstable piece of shit. The tinycorelinux people tried
them out for their package system and had to give up and use the
"hack" instead.

[dev] Linking a directory tree of configuration files

[Thomas Levine]

Having trouble installing rcm on some computers, I came up with the
following alternative a couple weeks ago. I have been pleased.
https://thomaslevine.com/scm/lntree/
https://thomaslevine.com/scm/lntree/uv/lntree-0.1.tar.gz

Here is an example of where I have used it to compose configurations.
https://thomaslevine.com/scm/os/artifact?ln=17..25=fb261310832d4eb6

Does something else like this exist? I could do without some of the
features; for example, it would be acceptable to have something like
cp -R that differed only in that it made hard links instead of copies.

Also, while I do like how this is working, I suspect that it could be
resolved more cleanly by designing the filesystem better. Consider,
for example, the following rules.

* All configuration files are stored in only a couple places so that
  they are easy to find and commit to version control.
* There are separate directories for private and public files so that
  they can easily be put in separate version control repositories.
* Directories containing configuration files do not contain any garbage,
  such as caches, examples, nor big files.

This way, you could put the configuration locations directly into
version control, without creating so many links. I am not pleased with
these rules, but they should give you an idea of what I am thinking.