On Wed, Jun 04, 2014 at 09:32:11PM +0200, Roberto E. Vargas Caballero wrote:
> Maybe the use of && to allow sequential code in a 'if' is not a good idea,
> and maybe some refactoring could be done here to avoid so long lines and
> the ugly sequential &&.
You’re right, I gave it a try and actually
Refactor the SNAP_WORD part in selsnap, and fix a bug that caused the word
delimiters to be ignored if it was at the very beginning or end of a wrapped
line.
---
st.c | 40 +---
1 file changed, 17 insertions(+), 23 deletions(-)
diff --git a/st.c b/st.c
index e0
A few style questions:
> - if(*y > 0 && term.line[*y - 1][term.col-1].mode
> - & ATTR_WRAP) {
> + if(*y > 0 && term.line[*y-1][term.col-1].mode &
> ATTR_WRAP
> +
> Yeah, I made this so that it apply cleanly on the head but forgot to
> rebase it on my other patch. Here is the fixed version, sorry!
Applied, thanks!
--
Roberto E. Vargas Caballero
> > Before he gets in, he still has to run a brute-force/dictionary-att. on
> > all users. He wouldn't have much time if the admins have done their
> > jobs.
>
> Well no. Think about sysadmins who have to allow users to run crappy
> PHP code on a shared server (so glad I'm not one of those people
On Wed, Jun 04, 2014 at 06:52:11PM +0200, FRIGN wrote:
> On Wed, 4 Jun 2014 17:44:14 +0100
> Dimitris Papastamos wrote:
>
> > declaring variables in the middle of the block is not my practice.
> > I am not embracing all features of C99, I use a mix of C90 and C99
> > without sacrificing portabili
On Wed, 4 Jun 2014 17:44:14 +0100
Dimitris Papastamos wrote:
> declaring variables in the middle of the block is not my practice.
> I am not embracing all features of C99, I use a mix of C90 and C99
> without sacrificing portability (as far as I can).
Same here, that's why I changed it to _not_
On Wed, Jun 04, 2014 at 06:32:50PM +0200, FRIGN wrote:
> On Wed, 4 Jun 2014 16:31:47 +0100
> Dimitris Papastamos wrote:
>
> > uint_least64_t is C99.
>
> Well, it's your choice to take it or not. If you don't like it, you can
> implement the changes to the inherent variable-declarations in the
>
On Wed, 4 Jun 2014 12:22:04 -0400
Nick wrote:
> Well no. Think about sysadmins who have to allow users to run crappy
> PHP code on a shared server (so glad I'm not one of those people at
> the moment). An attacker can execute commands as a web user,
> probably far easier than brute-forcing an
On Wed, 4 Jun 2014 16:31:47 +0100
Dimitris Papastamos wrote:
> uint_least64_t is C99.
Well, it's your choice to take it or not. If you don't like it, you can
implement the changes to the inherent variable-declarations in the
middle of blocks only to at least get the separation right.
Cheers
FR
Quoth FRIGN:
> Before he gets in, he still has to run a brute-force/dictionary-att. on
> all users. He wouldn't have much time if the admins have done their
> jobs.
Well no. Think about sysadmins who have to allow users to run crappy
PHP code on a shared server (so glad I'm not one of those peop
On Wed, Jun 04, 2014 at 12:00:41PM -0400, Lee Fallat wrote:
> Just a quick question that is somewhat related: will ubase compile on
> the BSDs, and possibly Plan 9 (using APE) ?...
not ubase. ubase specifically exists for all programs that are inherently
not portable. All tools in ubase depend o
Use printf("%*s", n, "") instead of allocating
a string filled with spaces.
>From 3cf11b384e2cf0a61c3bbf6a887d301897fecb08 Mon Sep 17 00:00:00 2001
From: Jakob Kramer
Date: Wed, 4 Jun 2014 17:46:22 +0200
Subject: [PATCH] cols: simplify filling with spaces
Use printf("%*s", n, "") instead of alloc
On Wed, Jun 4, 2014 at 5:51 PM, FRIGN wrote:
> Code is written wronce and read many times. I don't know about you, but
"wronce"... interesting idea. You could get it right the first time,
but popular ongoing debate seems to have established well enough that
the programmer tries to converge to bei
On Wed, 4 Jun 2014 12:00:41 -0400
Lee Fallat wrote:
> Just a quick question that is somewhat related: will ubase compile on
> the BSDs, and possibly Plan 9 (using APE) ?...
Good question.
Well, this doesn't make much sense, as ubase is the set of linux base
utils. sbase is the way to go for uni
Just a quick question that is somewhat related: will ubase compile on
the BSDs, and possibly Plan 9 (using APE) ?...
On Wed, Jun 4, 2014 at 11:51 AM, FRIGN wrote:
> On Wed, 4 Jun 2014 11:46:18 -0400
> Nick wrote:
>
>> Umm. In what way is the trailing comma an error? Leaving trailing
>> commas in
On Wed, 4 Jun 2014 17:40:39 +0200
"Roberto E. Vargas Caballero" wrote:
> WOW!, so, for you, it isn't important if you have a non legitimate
> user, that can use your machine as base for attacking another
> machines.
> And, of course, it isn't important if you have an atacker
> in your system with
On Wed, 4 Jun 2014 17:46:40 +0200
Markus Teich wrote:
> So for systems with large user counts it is easier to find a user with a weak
> password, but it does not influence your user account at all if you use a
> strong
> (strong = password is not one of the n most common ones) password.
And in
On Wed, 4 Jun 2014 11:46:18 -0400
Nick wrote:
> Umm. In what way is the trailing comma an error? Leaving trailing
> commas in structs is always reasonable (as far as I know), so you
> can move things around / add things without messing with the last
> line. Is there some reason you wouldn't wa
On Wed, 4 Jun 2014 16:31:47 +0100
Dimitris Papastamos wrote:
> uint_least64_t is C99.
Check stdint.h, where it actually calls the extension for 64bit-types.
For full C90-compatibility we would of course need to take care of this
in a deeper way, but this way, no functionality is lost.
--
FRIGN
Quoth FRIGN:
> Add -pedantic to CFLAGS to spot errors like the one in eject.c.
>
> [snip]
>
> diff --git a/eject.c b/eject.c
> index 7d458e8..62f42fa 100644
> --- a/eject.c
> +++ b/eject.c
> @@ -10,7 +10,7 @@
>
> enum {
> CDROM_EJECT = 0x5309,
> - CDROM_CLOSE_TRAY = 0x5319,
> + CDR
Heyho,
FRIGN wrote:
> In which way is a /etc/passwd with hundreds of users less secure than a
> smaller one? Do many hashes in one place magically reduce the overall
> security?
Not precisely. But if you have a large amount of users, the probability that one
of them chose a weak common password i
> Well, who cares if one of them uses a weak password?
WOW!, so, for you, it isn't important if you have a non legitimate
user, that can use your machine as base for attacking another
machines. And, of course, it isn't important if you have an atacker
in your system with all the time of the world
On Wed, Jun 04, 2014 at 05:28:50PM +0200, FRIGN wrote:
> Given ubase was already very close to compile with c90-mode enabled,
> why not do it then?
> Basically, it involved switching to uint_least64_t instead of unsigned long
> long
> and improving some dynamic-array magic.
uint_least64_t is C99.
On Wed, 4 Jun 2014 17:28:02 +0200
"Roberto E. Vargas Caballero" wrote:
> It is not about the security of /etc/passwd, it is about you cannot
> ensure that hundred of users will use strong password, because you don't
> select theirs passwords, so at the end the security of your system
> depend of
> In which way is a /etc/passwd with hundreds of users less secure than a
> smaller one? Do many hashes in one place magically reduce the overall
> security?
It is not about the security of /etc/passwd, it is about you cannot
ensure that hundred of users will use strong password, because you don't
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
>From 9f60534b97c25c6dcd81c72
On Wed, 4 Jun 2014 17:14:19 +0200
"Roberto E. Vargas Caballero" wrote:
> The problem arises when you have a system with hundred of users. You have
> to ensure that all the users have a strong password (some of them without
> any basic knowledge about computers or security), so the only way is
> m
> Thus, the shadow file locks things up a bit more, brings some more
> complexity, but this doesn't mean /etc/passwd is insecure.
> If you use strong passwords, you don't need the shadow-file. If you
> have a weak password, the shadow-file on the other hand just delays the
> eventual breach.
The p
On Tue, Jun 03, 2014 at 09:05:23PM +0200, hiro wrote:
> choose a stream, meaning of itags is on wikipedia article of youtube.
> wget -q -O - 'http://www.youtube.com/watch?v=Ux1Za8Wmz_s'|sed
> 's/"/\n/g; s/\\u0026/ /g; s/,/\n/g'|sed -n
> '/url_encoded_fmt_stream_map/,/^$/p; /adaptive_fmts/,/^$/p'
>
On Wed, Jun 04, 2014 at 02:21:51PM +0200, FRIGN wrote:
> On Wed, 4 Jun 2014 12:55:39 +0100
> Dimitris Papastamos wrote:
>
> > The implementation turned out to be simple enough. Factoring out
> > the routines in util/ should make the code more readable.
>
> The similarities between su and login
On Wed, 4 Jun 2014 12:55:39 +0100
Dimitris Papastamos wrote:
> The implementation turned out to be simple enough. Factoring out
> the routines in util/ should make the code more readable.
The similarities between su and login are a good reason to do the
handling in one place.
--
FRIGN
On Wed, Jun 04, 2014 at 12:44:01PM +0200, FRIGN wrote:
> Looking at it from the programmer's side: Implementing /etc/shadow
> brings more complexity to the program. Avoiding complexity is one goal
> to set, thus avoiding /etc/shadow is a good way to simplify things.
The implementation turned out t
On Wed, Jun 04, 2014 at 12:44:01PM +0200, FRIGN wrote:
> On Wed, 4 Jun 2014 00:15:58 +0200
> Alexander Huemer wrote:
>
> > You think so? That's not at all what I personally associate with this
> > feature. Can you elaborate?
>
> Many people don't understand how hashing-functions work.
Obviousl
On Wed, 4 Jun 2014 00:15:58 +0200
Alexander Huemer wrote:
> You think so? That's not at all what I personally associate with this
> feature. Can you elaborate?
Many people don't understand how hashing-functions work. The
shadow-file might suggest knowing the hash inherently unveils the
password
If a word delimiter was at the very beginning or end of one of the
different lines composing a wrapped line, the delimiter was ignored for
word selection. This now checks for delimiters before moving on to the
next part of a wrapped line.
---
st.c | 9 +
1 file changed, 5 insertions(+), 4
36 matches
Mail list logo
