Re: [dev] Re: st: Use after free

[Martin Kühne]

On Mon, Jan 23, 2017 at 5:11 AM,   wrote:
> What I believe[...]

Whose responsibility would it be to test what you believe? It looks a
lot like you expect us to figure out whether you are on to something
relevant. I had a dream last night and in that dream I saw the
glorious future of a moosotc figuring things out on his own. The
issues, progress and the personal role that derives from what we
accomplish this way is what gets us to places in life.

cheers!
mar77i

[dev] Internet privacy/decentralisation projects

[Caleb Malchik]

Greetings,

I was wondering what the suckless community thinks about various
projects aimed at Internet decentralisation and privacy - some of
which are listed here [0]. Are there any projects in this area that
are particularly promising from a suckless perspective?

My personal reason for asking is that I have the opportunity this
spring to get paid to contribute to an open source project of my
choosing, which has a "democracy-enhancing" (or preserving) effect. Of
course all Suckless projects are democracy-enhancing in a way, but for
this I'm looking at projects with more of a focus on societal impact
and the potential for mass adoption. Projects I've looked at include
IPFS [1], cjdns [2], and Tox [3].

I am a relatively inexperienced programmer, so I am eager to hear what
more experienced folks have to say on this matter :)

Cheers,
Caleb

[0] https://github.com/redecentralize/alternative-internet
[1] https://ipfs.io/
[2] https://github.com/cjdelisle/cjdns
[3] https://tox.chat/

[dev] Re: st: Use after free

[moosotc]

moos...@gmail.com writes:

> `valgrind st -f mono-2 cat full-bmp.txt' [1]
>
> Yields quite a few invalid reads from freed blocks, the issue is related
> to cache management. In the real world those dangling pointer issues
> lead to segfaults or X11 errors (eventually)
>
> [1] http://www.cl.cam.ac.uk/~mgk25/ucs/full-bmp.txt

What I believe happens is this:

in xmakeglyphfontspecs
if (frclen >= LEN(frc)) {
frclen = LEN(frc) - 1;
XftFontClose(xw.dpy, frc[frclen].font);
frc[frclen].unicodep = 0;
}

but the font can be current in dc, and somehow xdrawglyphfontspecs uses
freshly freed font.

-- 
mailto:moos...@gmail.com

Re: [dev] st: Use after free

[moosotc]

Hiltjo Posthuma  writes:

> On Sun, Jan 22, 2017 at 11:00:28PM +0300, moos...@gmail.com wrote:
>> Martin Kühne  writes:
>> 
>> > On Sun, Jan 22, 2017 at 5:17 PM,   wrote:
>> >>
>> >> `valgrind st -f mono-2 cat full-bmp.txt' [1]
>> >>
>> >> Yields quite a few invalid reads from freed blocks, the issue is related
>> >> to cache management. In the real world those dangling pointer issues
>> >> lead to segfaults or X11 errors (eventually)
>> >>
>> >
>> >
>> > I think your patch might have been lost on the way?
>> >
>> 
>> Nope - there was no patch since I don't really understand what's going
>> on, I only have symptoms and reproducer.
>> 
>> -- 
>> mailto:moos...@gmail.com
>> 
>
> Hi,
>
> Not to be mean, but please learn more about Valgrind (and it's caveats)
> before posting to the ML. It is expected to provide a patch fix or at the
> very least give detailed information.

`st cat ~/x/txt/full-bmp.txt -
zsh: segmentation fault (core dumped)  st cat ~/x/txt/full-bmp.txt -`

That's after 4-5 runs of st, not the absence of valgrind in the above
command line, with valgrind the splats are predictable and stable,
always pointing to the same stack trace at least.

I would love to provide a patch, but as mentioned before I don't really
understand the code in question.

-- 
mailto:moos...@gmail.com

Re: [dev][announce] lr: tiny log rotater

[Quentin Rameau]

> I’ve seen your opinions on this point a few times and understand your
> position, although I don’t agree with it. Briefly, and without wanting
> to start a flamewar: whatever convenience or legal protection licenses
> provide, they are philosophically very different from a dedication to
> the public domain. The public domain is too great an idea to give up
> out of fear of country %s’s interpretation of it. BSD/MIT/ISC may be
> “100% legally waterproof”, but they are totally inferior in spirit to
> the old hacker license: “share and enjoy”.

Yes.

Re: [dev][announce] lr: tiny log rotater

[Laslo Hunhold]

On Sun, 22 Jan 2017 15:48:00 -0500
Wolfgang Corcoran-Mathe  wrote:

Hey Wolfgang,

> I’ve written a simple log rotation program. It rotates a given file
> through n backups, appending a numeric suffix. Logs may also be piped
> through a command, and an optional suffix may be appended.
> 
> lr is static and is configured solely through command-line flags.
> There is no built-in support for periodic rotation (e.g. every two
> weeks, or when a file has reached a given size), which is better
> handled by external utilities.
> 
> It is a very boring program. Unlike logrotate, however, it is
> fairly sane.

Alexander raises a valid point. Log rotation, with growing hard drive
space, is becoming less and less relevant, however, I can see the uses
for some applications.

The topic of licensing came up, so let me say a few words about it: If
you want to maximize the number of people benefitting from your code,
then you should not put it in the public domain. Period.
I and many on this ml have seen the big mess that came up when Google
actually did not want to use musl for an internal project because parts
of musl were licensed as public domain. Given public domain is not
well-defined globally, it's more of an "all rights reserved" and
companies are (rightfully) very careful when they plan to integrate a
piece of software into their set of tools.

---

Okay, so how do you construct a simple, but effective license for your
needs? Given we are very liberal about software here, there are only
two choices we might make when we give a license to something: Do we
want to be attributed or not?

If the answer is yes, we use the standard ISC-header[0]:

Permission to use, copy, modify, and/or distribute this
software for any purpose with or without fee is hereby granted,
provided that the above copyright notice and this permission
notice appear in all copies.

If not, we use the standard "ISC"-header, but without the attribution
clause at the end. This is also known as the BSD 0-Clause License[1]
(0BSD):

Permission to use, copy, modify, and/or distribute this
software for any purpose with or without fee is hereby granted.

After that, we add the warranty-block, which is the same for every
license. The ISC-license provides a nice one that has been simplified
based on some international terms agreed upon at the Berne convention:

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR
CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

To make it easier for people to see which license it is, add a

ISC-License

or

0BSD-License

at the very top of your LICENSE file. COPYING or COPYRIGHT is not a good
name for this file, given the license not only covers copying the code,
but what also applies to compilates and your disclamation of any
implied warranty. Also, from my experience, I much more often encounter
LICENSE rather than COPYING and it's the first thing I look for in a
codebase.

---

I also don't see the value in public domain really, given the choices
above which are 100% legally waterproof, easy to understand as the
legal concepts are well-drawn and well-established in the free
software community and even at corporations.
Legally speaking, you _never_ lose your copyright in something. And
tell me one aspect where 0BSD is in any way inferior to Public Domain.
It just complicates things and as you've seen above, you can really use
two simple licenses for your daily needs. On the other hand, public
domain might really hinder your software from being used by
corporations who have to keep their checks in place. If you argue that
corporations are evil let me remind you that in the long run, them
using good, clean, well-tested open source code is much more beneficial
to the users of their software than them handrolling a crappy solution
in a few days on a tight budget.

And as a last piece of advice: Never allow your codebase to host
multiply-licensed code if you can prevent it. Legacy codebases are of
course and exception, but if you happen to stumble upon a GPL-fanatic
or a PD-fanatic who just does not agree to license his submission under
the license imposed by the project, it might not even be worth it to
merge his changes. It's just complicated to read a gem like this[2],
where it's not even well-defined what certain parts of a code are
actually licensed as.

With best 

Re: [dev] st: Use after free

[Hiltjo Posthuma]

On Sun, Jan 22, 2017 at 11:00:28PM +0300, moos...@gmail.com wrote:
> Martin Kühne  writes:
> 
> > On Sun, Jan 22, 2017 at 5:17 PM,   wrote:
> >>
> >> `valgrind st -f mono-2 cat full-bmp.txt' [1]
> >>
> >> Yields quite a few invalid reads from freed blocks, the issue is related
> >> to cache management. In the real world those dangling pointer issues
> >> lead to segfaults or X11 errors (eventually)
> >>
> >
> >
> > I think your patch might have been lost on the way?
> >
> 
> Nope - there was no patch since I don't really understand what's going
> on, I only have symptoms and reproducer.
> 
> -- 
> mailto:moos...@gmail.com
> 

Hi,

Not to be mean, but please learn more about Valgrind (and it's caveats)
before posting to the ML. It is expected to provide a patch fix or at the
very least give detailed information.

-- 
Kind regards,
Hiltjo

Re: [dev][announce] lr: tiny log rotater

[Alexander Krotov]

On Sun, Jan 22, 2017 at 03:48:00PM -0500, Wolfgang Corcoran-Mathe wrote:
> Hi all,
> 
> I’ve written a simple log rotation program. It rotates a given file
> through n backups, appending a numeric suffix. Logs may also be piped
> through a command, and an optional suffix may be appended.
> 
> lr is static and is configured solely through command-line flags.
> There is no built-in support for periodic rotation (e.g. every two
> weeks, or when a file has reached a given size), which is better
> handled by external utilities.
> 
> It is a very boring program. Unlike logrotate, however, it is
> fairly sane.
> 
> 
> Examples:
> 
> Rotate /var/log/messages through 3 backups (messages.[1-3]):
> 
> lr -n 3 /var/log/messages
> 
> Pipe each backup through bzip2 and add .bz2 suffix:
> 
> lr -n 3 -c bzip2 -s .bz2 /var/log/messages
> 
> 
> Mercurial repository:
> 
> http://www.sigwinch.xyz/hg/lr
> 
> Comments, pull requests and patches are welcome, of course.
> 
> Regards,
> 
> -- 
> wcm
> 

Just noticed I have no log rotation on my desktop at all and still only
16M of logs.

Just tried this one: lr -n 3 /var/log/messages moved the file to
/var/log/messages.1, but messages are still added to messages.1, not
messages. Is it intended? Looks like just relinking the file does not
work as expected, you also have to do "killall -HUP syslog-ng" or
whatever you use.

Added this one to cron.daily:

  lr -n 3 /val/log/messages
  killall -HUP syslog-ng

Might want to add it to readme.

As for license, you may want to use http://unlicense.org/

> If the laws in your area are brain-damaged
Copyright laws are brain-damaged almost everywhere with respect to
public domain and link to wikipedia about ISC license instead of actual
license text is even less likely to have any legal effect than public
domain dedication.

[dev] [blind] 1.0 release

[Mattias Andrée]

Hello World!

I am pleased to announce the first release of blind[0]:
version 1.0[1].

blind command line video editor designed primarily for
creating new videos. blind uses a raw video format with
a very simple container. The raw video uses CIE XYZ
encoded with `double`s, with an alpha channel. The blind
tools avoid using parameters give in the command line
as much as possible, and instead use videos, for examples
to blurring a video you use blind-gauss-blur, but
gauss-blur does not have an option for selecting the
standard deviation, instead it expects a video file with
these values, which allows for non-uniform blurring and
time-based blurring.

To use blind, you need to have ffmpeg installed. ffmpeg
is used by the tool that convert video file into the
format blind uses, and by the tool that makes the
conversion in the opposite direction. You may also want
to have ImageMagick installed this is however optional,
but if you do not have it installed, you will have to
manually specify either farbfeld or PAM when converting
to or frame images. No other image format is supported
without ImageMagick.

blind is a video-only editor, you have to use other
tools for editing the audio. ffmpeg can be used to add
audio into a video file, extract audio, or concatenate
audio file.

One problem at the moment is that, unless you want to
rip your hair out, you will need a shell that supports
process substitution, which unfortunately is not too
common. Korn shell, Bash, and if I am not mistaken, rc,
are the only shells I know that supports this. However,
I'm working a sh(1p)-implementation (that will not
support even close to everything sh(1p) specifies)
that will support process substitution as well as
provide access to pipe(3) for more complicated pipelines.

[0] http://tools.suckless.org/blind/
[1] http://dl.suckless.org/tools/blind-1.0.tar.gz


pgp6uLEOJNzzR.pgp
Description: OpenPGP digital signature

Re: [dev] st: Use after free

[moosotc]

Martin Kühne  writes:

> On Sun, Jan 22, 2017 at 5:17 PM,   wrote:
>>
>> `valgrind st -f mono-2 cat full-bmp.txt' [1]
>>
>> Yields quite a few invalid reads from freed blocks, the issue is related
>> to cache management. In the real world those dangling pointer issues
>> lead to segfaults or X11 errors (eventually)
>>
>
>
> I think your patch might have been lost on the way?
>

Nope - there was no patch since I don't really understand what's going
on, I only have symptoms and reproducer.

-- 
mailto:moos...@gmail.com

Re: [dev] st: Use after free

[Martin Kühne]

On Sun, Jan 22, 2017 at 5:17 PM,   wrote:
>
> `valgrind st -f mono-2 cat full-bmp.txt' [1]
>
> Yields quite a few invalid reads from freed blocks, the issue is related
> to cache management. In the real world those dangling pointer issues
> lead to segfaults or X11 errors (eventually)
>


I think your patch might have been lost on the way?

cheers!
mar77i

[dev] st: Use after free

[moosotc]

`valgrind st -f mono-2 cat full-bmp.txt' [1]

Yields quite a few invalid reads from freed blocks, the issue is related
to cache management. In the real world those dangling pointer issues
lead to segfaults or X11 errors (eventually)

[1] http://www.cl.cam.ac.uk/~mgk25/ucs/full-bmp.txt

-- 
mailto:moos...@gmail.com