Hello,
as already announced, I fixed some parts of the code to make
ubase compilable in C89/C90-mode.
Sometimes, (unsigned long long)-casts were not necessary. Read the
manuals.
Add -pedantic to CFLAGS to spot errors like the one in eject.c.
Cheers
FRIGN
--
FRIGN d...@frign.de
From
to valuable services, it is
nonetheless mandatory to make sure their passwords are safe. However,
who would let a n00b manage important stuff?
Cheers
FRIGN
--
FRIGN d...@frign.de
is lost.
--
FRIGN d...@frign.de
a trailing comma.
It's actually non-defined behaviour according to the standard. It'd be
ok if the standard said it was arbitrary if there are trailing commas
or not, but at the moment, the compiler is just generous enough to
ignore it and just pops a warning with -pedantic.
Cheers
FRIGN
--
FRIGN d
ones) password.
And in the end you still check against all hashes ;).
Nice approach with the probability-theory!
Cheers
FRIGN
--
FRIGN d...@frign.de
for the recommendation!
Cheers
FRIGN
--
FRIGN d...@frign.de
is the way to go for unix in general.
Cheers
FRIGN
--
FRIGN d...@frign.de
.
Cheers
FRIGN
--
FRIGN d...@frign.de
of remove) is just an 'unprivelaged'
web user.
Yep, that's true! In many cases comfort is the biggest vulnerability in
modern web-applications and services.
--
FRIGN d...@frign.de
it to _not_ declare them in the middle
of the block ;) (check the patch).
Mixing C90 and C99 with best of both worlds is really a good idea.
Cheers
FRIGN
--
FRIGN d...@frign.de
to check the length of the hash, given a
shadow-password is easy to identify with 'x','\0'.
My patch is attached; I'd be glad to see it applied for all people who
know that shadow-passwords only give a false sense of security.
Cheers
FRIGN
--
FRIGN d...@frign.de
From
On Tue, 3 Jun 2014 18:32:13 +0100
Dimitris Papastamos s...@2f30.org wrote:
On Tue, Jun 03, 2014 at 07:28:37PM +0200, FRIGN wrote:
- if(num !iscntrl((int) buf[0]) (len + num
sizeof passwd)) {
+ if(num !iscntrl((int) buf[0]) (len
physical access to a Linux box, I'll get access to it.) So knowing a
password isn't necessary any more.
Exactly. This is a rather trivial issue and for instance not relevant
for ssh, telnet and other means of non-local access.
Cheers
FRIGN
--
FRIGN d...@frign.de
On Tue, 3 Jun 2014 22:44:31 +0200
Alexander Huemer alexander.hue...@xx.vu wrote:
What here provides a false feeling of security?
Well, the incorporation of this shadow-file.
Some users might see this as a motivation for weak passwords.
Cheers
FRIGN
--
FRIGN d...@frign.de
Hello,
I was very glad to see the initial implementation of login by sin, but
found some stuff that simplifies the code even more.
Check the patch for more details, it should speak for itself.
Cheers
FRIGN
--
FRIGN d...@frign.de
From b39d86ebdaadfe4880fd1681bd021ea06ecadb75 Mon Sep 17 00:00
dependency.
Cheers
FRIGN
--
FRIGN d...@frign.de
the shadow-file.
In reality, it's a solution for a very unimportant issue.
If your password is strong, having the hashes won't help any attacker.
On the other hand, having a weak password, the shadow-file doesn't save
you from a breach.
Cheers
FRIGN
--
FRIGN d...@frign.de
to your patch, which removed the temporary variables.
It wouldn't overwrite dc.col's adress in case something fails
internally, but it is a memleak the way I did it, because dc.col is not
freed before being re-assigned.
Cheers
FRIGN
--
FRIGN d...@frign.de
-parser.
This works perfectly for the suckless-wiki and I see no reason why this
shouldn't work in any other place.
Cheers
FRIGN
--
FRIGN d...@frign.de
all kinds of weird
tricks and hacks, which only seem to work with established emulators.
Cheers
FRIGN
--
FRIGN d...@frign.de
this additional cut will bring!
Cheers
FRIGN
--
FRIGN d...@frign.de
fixed this issue. So there's no point in discussing it anyway.
Cheers
FRIGN
--
FRIGN d...@frign.de
(i, NULL). I'd be glad if you did this, as unfortunately,
I do not have access to development environment right now.
Alright, here is the fixed updated patch with improved xloadcols and
just a little bit simpler.
Cheers
FRIGN
--
FRIGN d...@frign.de
From ea8710419dae48ccd4e86ea7b70378317e0035c9
not when our gamma-scaling is
messed up.
Cheers
FRIGN
--
FRIGN d...@frign.de
().
If I'm wrong, let me know. If not, we could skip the entire if(!
name)-part.
Cheers
FRIGN
--
FRIGN d...@frign.de
From b1f44d918f982341a4b890777cb2a9d3937b6bce Mon Sep 17 00:00:00 2001
From: FRIGN d...@frign.de
Date: Sun, 25 May 2014 12:13:22 +0200
Subject: [PATCH] Refactor xsetcolorname()
I
On Sun, 25 May 2014 12:23:43 +0200
FRIGN d...@frign.de wrote:
If I'm wrong, let me know. If not, we could skip the entire if(!
name)-part.
Well, I just found out I was partially wrong:
With echo -e '\e]104\a' and echo -e '\e]104;1\a' you can reset certain
colors to their initial values
On Sun, 25 May 2014 12:38:05 +0200
FRIGN d...@frign.de wrote:
Well, I just found out I was partially wrong:
Just to make it clear: It doesn't invalidate the patch in any way. It
was just a false assumption over the nature of the function.
--
FRIGN d...@frign.de
it's done right. If st does the calculations
right, unlike xterm, I'd suggest letting the xterm-guys know.
Cheers
FRIGN
--
FRIGN d...@frign.de
designed visually.
I wrote this patch to adress two things:
First, fix xdraws() to make it more consistent and work by a valid
colour-model (according to the points given above and Eric's patch).
Second, simplify the loops in xloadcols and other minor simplifications.
Cheers
FRIGN
[0]: http
predictability (imho, all other terminals overcomplicate
color-management). And that's why I agree on the copy-part, which
definitely needs to be fixed, as the software behaves unpredictably.
Cheers
FRIGN
--
FRIGN d...@frign.de
in accordance to the palette that xterm uses.
Predictability =!= Common Behaviour.
Just because everyone does it, doesn't make it right!
--
FRIGN d...@frign.de
to me.
Read this: http://www.4p8.com/eric.brasseur/gamma.html
We need to generally re-think the algorithm used here. I hate the idea
of being conformant to this or that terminal emulator and instead
prefer an implementation according to how it's defined (!).
Cheers
FRIGN
--
FRIGN d...@frign.de
,
dependency-resolution and global-updates, I'm currently working on a
concept for a build-system very similar to what has already been done
in morpheus with the ports-makefiles.
Cheers
FRIGN
--
FRIGN d...@frign.de
On Wed, 14 May 2014 13:46:07 +0200
Thuban thu...@yeuxdelibad.net wrote:
Hi all,
I was wondering if there is any existing solution to have dmenu
understanding regular expression?
Hey Thuban.
Regexes in which context?
Cheers
FRIGN
--
FRIGN d...@frign.de
FRIGN
--
FRIGN d...@frign.de
the rights to use, copy, modify, merge, publish,
distribute, sublicense and/or sell the software, stressing what we
consider most important.
And if there is any consensus on this, can we display it somewhere
visible on the wiki?
Nice idea!
Cheers
FRIGN
--
FRIGN d...@frign.de
Hello,
I decided to state my clear name in the licenses of the programs I
submit to.
Thus, to complete the change, I send in this patch to change the
sbase-license accordingly.
Cheers
FRIGN
--
FRIGN d...@frign.de
From 9146781ff0ac4ceb421281ab6afda6f246c4d031 Mon Sep 17 00:00:00 2001
From
Hello,
reading the grep-code in sbase kind of left me wondering why this enum
was implemented. In the contexts it's been used it doesn't make much
sense and obfuscates the code.
Cheers
FRIGN
--
FRIGN d...@frign.de
From 48912a55e9122fd221d5f9c800b679ceaa622f53 Mon Sep 17 00:00:00 2001
From
this and
doesn't add much complexity to the code.
I second this!
Cheers
FRIGN
--
FRIGN d...@frign.de
On Sun, 11 May 2014 23:20:26 +0200
FRIGN d...@frign.de wrote:
reading the grep-code in sbase kind of left me wondering why this enum
was implemented. In the contexts it's been used it doesn't make much
sense and obfuscates the code.
I should've read the manual[0] a bit more attentively
me know what you think!
Cheers
FRIGN
--
FRIGN d...@frign.de
From 2cd038b2b1cbe9985c5bceeebc511e898f289855 Mon Sep 17 00:00:00 2001
From: FRIGN d...@frign.de
Date: Mon, 12 May 2014 00:31:07 +0200
Subject: [PATCH] Make grep more memory-efficient
---
grep.c | 38
been thinking about scrapping xdg-open completely and make soap
configurable in a way that it doesn't need to rely on xdg-open any more.
I personally am sick of this system!
Cheers
FRIGN
PS:
http-helper.sh
xdg-utils.
Read the makefile.
BTW, what is wrong with just using st dmenu for this stuff?
see above.
Cheers
FRIGN
--
FRIGN d...@frign.de
clean make install
to provide the same functionality?
Cheers
FRIGN
--
FRIGN d...@frign.de
to consider is that mailcap isn't
called by X-programs, which soap is directed at (- replacing xdg-open).
Cheers
FRIGN
--
FRIGN d...@frign.de
bloated, but that's not advanced. The strict
dependence on mimes (still, no custom URL-parsing!) makes it rather
unfavorable and is, again, not meant to replace xdg-open.
Cheers
FRIGN
[1]: https://github.com/hut/ranger/blob/master/ranger/config/rifle.conf
--
FRIGN d...@frign.de
. This
concept is already working great for dwm and other pieces of suckless
software.
Cheers
FRIGN
--
FRIGN d...@frign.de
this minor side-issue of broken
escapes in the manpage and be done with it. I got more important stuff
to do than discussing this crap for days on this mailing list.
The time we spent discussing we could've written so much more
productive code.
Cheers
FRIGN
--
FRIGN d...@frign.de
On Sun, 4 May 2014 18:52:25 +0800
Chris Down ch...@chrisdown.name wrote:
FRIGN writes:
A configuration can look like this:
{ \.mp3,st -e mplayer %s },
{ \.(jpg|png|tiff)$,feh %s},
{ \.gif,wget -O /tmp/tmp.gif %s gifview -a
/tmp/tmp.gif
what my colleagues use, if
they can't get their act together and make the switch.
Now, maybe another example would be more suitable, like pressing a
YouTube-link in Gajim or w/e. You know what I mean ;).
Cheers
FRIGN
--
FRIGN d...@frign.de
with the raw
argv[1], but only with the safely escaped version of it.
Cheers
FRIGN
--
FRIGN d...@frign.de
to executing
this command:
{ \.mp3, st -e mplayer %s }
This behaviour is consistent across most terminal emulators I know.
Now, we might ask ourselves if this really is a deficiency in soap or a
general shell-concern, which has already been adressed broadly.
Cheers
FRIGN
--
FRIGN d
waste it by recommending
it too early to non-proficient users.
Cheers
FRIGN
--
FRIGN d...@frign.de
things which may exclude this possiblity, but as
long as you know what you're doing, soap is perfectly safe to use.
Cheers
FRIGN
--
FRIGN d...@frign.de
irony: Discussing security-non-issues while using OpenSSL.
Cheers
FRIGN
--
FRIGN d...@frign.de
to only call external shell-scripts kind of defeats the
purpose and only pushes the non-problem on a different stack.
For single commands + arguments, the exec*-calls are definitely
superior, though!
Cheers
FRIGN
--
FRIGN d...@frign.de
(which right now it is not).
Yep, that's right. I'll do just that, as already said in an earlier
response, to make sure no one runs into this problem.
Cheers
FRIGN
--
FRIGN d...@frign.de
-compositors (by
choice), ...), and I'm not talking about fancy compositing, but just
basic ways of building and integrating user interfaces.
What do you think?
Cheers
FRIGN
--
FRIGN d...@frign.de
. sizeof is not a function!
#define LEN(a) (sizeof a / sizeof *a)
is the right way to do it.
The length of an array is the size of the array divided by the length
of each element's type.
However, I don't see any error in the way it was done before noname
suggested changing it.
Cheers
FRIGN
3) Somehow, all of your messages have been bouncing for me. I don't
know if this is coincidence or some error on my or the ml's behalf.
Cheers
FRIGN
--
FRIGN d...@frign.de
On Sun, 20 Apr 2014 20:13:02 +0100
sin s...@2f30.org wrote:
You are missing the parentheses there.
Your macro provides the wrong answer for something like:
int a[] = { 1, 2, 3, 4, 5 };
printf(%zu\n, LEN(a + 2));
Ah, that's right!
Thanks for noting this.
Cheers
FRIGN
--
FRIGN d
On Mon, 14 Apr 2014 12:51:25 +0100
Dimitris Papastamos d...@spl9.org wrote:
Interesting, maybe we could mention this in the wiki page and/or README.
Good idea!
But on which wiki-page particularly?
Cheers
FRIGN
--
FRIGN d...@frign.de
in the process.
Cheers
FRIGN
--
FRIGN d...@frign.de
to recommend as suckless or
do you like the idea of implementing it as a new project?
Cheers
FRIGN
[0]:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18
[1]: http://git.busybox.net/busybox/tree/shell/
[2]: http://git.kernel.org/cgit/utils/dash/dash.git/tree/
[3]: http
of hearing suckless and Python in the same
sentence, but I understand what you mean.
Refer to [0] for some pitfalls shared by our fellow Martin Kopta on his
blog[1].
[0]: http://mywiki.wooledge.org/BashPitfalls
[1]: http://martin.kopta.eu/blog/#2012-06-11-10-22-00
--
FRIGN d...@frign.de
taste.
Cheers
FRIGN
--
FRIGN d...@frign.de
does python not have scripting? Additionally, there are
programs that compile python...You've got me at piping though.
Well, I don't think you've ever read what a Python-compiler spits out
at the end. You would be amazed!
Cheers
FRIGN
--
FRIGN d...@frign.de
shell to rc to force myself to fully learn it
sometime soon, but it seems like a pretty great environment.
Hey Nick,
I'll check it out!
Cheers
FRIGN
--
FRIGN d...@frign.de
sketched the functionality in sh and
implied it to be implemented in C regardless.
Cheers
FRIGN
--
FRIGN d...@frign.de
all for a directory named ideas/ including working
shell-scripts of design-ideas, which can then be implemented as
C-programs later on.
This would both encourage new concepts and keep the repo clean of
problematic shell-scripts.
Cheers
FRIGN
--
FRIGN d...@frign.de
for a community of
skilled developers like OpenBSD to make OpenSSL suck less.
Imho, re-releasing it under OpenTLS would be a great idea!
What do you think about this fork finally getting rid of
backwards-compatibility and welcoming maintainable code and less bugs?
Cheers
FRIGN
[1]:
https://lobste.rs/s
, with switch_root ubase and sbase offer a great
toolbox for almost everything you would want to do with an initramfs.
Cheers
FRIGN
--
FRIGN d...@frign.de
On Mon, 14 Apr 2014 09:49:04 +0100
Dimitris Papastamos d...@spl9.org wrote:
A manpage for switch_root would be nice. For the style, have a look
at the existing manpages in ubase.
I planned on writing a manpage today. I'll send in a patch once it's
finished.
Cheers
FRIGN
--
FRIGN d
Hello,
as promised you can find the manpage for switch_root attached.
Cheers
FRIGN
--
FRIGN d...@frign.de
From cbda537178adeb75a488dd19fdb084757464271b Mon Sep 17 00:00:00 2001
From: FRIGN d...@frign.de
Date: Mon, 14 Apr 2014 15:26:11 +0200
Subject: [PATCH] Add switch_root manpage
On Mon, 14 Apr 2014 14:37:28 +0100
Dimitris Papastamos d...@spl9.org wrote:
Renamed it from switch_root.1 to switch_root.8.
Thanks, I forgot about that!
--
FRIGN d...@frign.de
/morpheus/ - the distro (basically config.mk
for mkbuild + ports)
[4] http://git.2f30.org/ports/ - our ports
Cool, this looks very clean!
Using aufs+namespaces to finally get rid of the PATH-madness is a great
idea. I'll stay tuned.
Cheers
FRIGN
--
FRIGN d...@frign.de
.
Cheers
FRIGN
--
FRIGN d...@frign.de
Good evening,
as discussed earlier, I worked on the switch_root-tool and successfully
tested it with my initramfs-setup without problems.
Let me know what you think.
Cheers
FRIGN
--
FRIGN d...@frign.de
From e0608f4fe61aa70a270b0168790fdd6994c3e91e Mon Sep 17 00:00:00 2001
From: FRIGN d
that, whatever crazyness is needed to get to
the super important sub nano-second user experience.
I rewrote the skript in C yesterday and we're discussing the design.
Cheers
FRIGN
--
FRIGN d...@frign.de
, but this got kind of lost in the process.
Now, Linux is often thought of to be the standard in the world of
UNIX-like operating system kernels. I'm glad it isn't.
For interoperatibility, I'm all for it!
Cheers
FRIGN
--
FRIGN d...@frign.de
would
approach it.
Cheers
FRIGN
PS: Researching this topic I stumbled upon this post[1].
A MkDirService? Seriously? Sometimes, I just feel sorry for the
Java-people.
[0]:
http://compgroups.net/comp.os.linux.development.apps/mkdir-and-thread-safety/261313
[1]:
http
(just think about the poor fs-implementors).
Cheers
FRIGN
--
FRIGN d...@frign.de
suckless a registered trademark and sue everyone who adopts our brand
without permission.
Cheers
FRIGN
--
FRIGN d...@frign.de
they say it looks dead
and bad.
DWM-screenshots never live up to its real nature, but I agree with you
on Ruby though, even though I prefer Java for everything.
We definitely need a window-factory for dwm. This should speed things
up considerably.
Cheers
FRIGN
--
FRIGN d...@frign.de
Well, I don't think this emphasizes the SUCKLESS® corporate-identity as much as
it should.
I propose we include underscores, too:
/usr/bin/_ST_
/usr/bin/_SSELP_
/usr/bin/_SURF_
/usr/bin/_DWM_
Cheers
FRIGN
On Wed, 2 Apr 2014 14:31:21 +0200
sta...@cs.tu-berlin.de wrote:
Thanks for bringing up
On Wed, 2 Apr 2014 14:36:00 +0200
Martti Kühne mysat...@gmail.com wrote:
Uh, you are aware that date this thread was from is over now, do you?
You must be fun at parties...
--
FRIGN d...@frign.de
decisions to the user! There are way too many irresponsible people out
there.
Well, why don't we move all our communication directly to Facebook?
Social Media is the future, and Mailing Lists are a thing of the past.
The Linux kernel guys did it already...[0]
Cheers
FRIGN
[0]: https
.
A StringBuffer is used to store the output.
--
Longer code usually is safer, because there are more ways to do it
right.
--
As of now, I only ported the echo-command into echo.java. More will
come.
Please let me know what you think about this great advancement.
Happy hacking!
Cheers
FRIGN
PS
On Tue, 25 Mar 2014 18:11:47 +0100
hiro 23h...@gmail.com wrote:
does it show anywhere the rtp stream setup process including the
hole-punching?
Not in the wiki sadly. Read the code.
--
FRIGN d...@frign.de
by just
tunneling it through SSH.
Cheers
FRIGN
--
FRIGN d...@frign.de
don't forget ossrecord | nc, and ossplay for the other direction.
I'm not familiar with OSS.
Cheers
FRIGN
[0]: http://wiki.tox.im/Audio_and_video
[1]: http://wiki.tox.im/Routing_Protocols
[2]: http://wiki.tox.im/Symmetric_NAT_Transversal
--
FRIGN d...@frign.de
socialism on our shores.
Well, not to become political, I think the complexity of SIP is based
on it's high modularity.
Cheers
FRIGN
--
FRIGN d...@frign.de
decreasing the
number of possible attack-vectors because tox-core's developers are
able to integrate such solutions very well knowing what's used in the
first place.
Regarding hole punching, read my other mail.
Cheers
FRIGN
--
FRIGN d...@frign.de
Tox in the making ;).
Cheers
FRIGN
--
FRIGN d...@frign.de
FRIGN
--
FRIGN d...@frign.de
–
the Unix philosophy.
That's a nice idea, Christoph. Then you could just keep on using
ii, sic or whichever IRC-client you prefer.
However, I see certain incompatibilities between Tox and IRC when it
comes to the structure of messaging (e.g. focus on p-chats).
Cheers
FRIGN
--
FRIGN d...@frign.de
of piece of software would bring the
suckless-philosophy closer to a bigger audience (and most probably
developers waiting to become professionals).
Cheers
FRIGN
--
FRIGN d...@frign.de
definitely bring in more trust into the Tox-IM-protocol, and, if it
turns out to be successful, in turn make the suckless-philosophy more
popular.
It was only coincidence that I heard of this great piece of software,
let's proceed and make something with it!
Cheers
FRIGN
[0]: https://github.com/nurupo
and they can directly add you.
This strong benefit is imho one of the key advantages over centralized
systems like those based on XMPP (Pidgin being a client).
Cheers
FRIGN
--
FRIGN d...@frign.de
Tox.
Cheers
FRIGN
--
FRIGN d...@frign.de
501 - 600 of 695 matches
Mail list logo
