>> That should be true only if you specify a listening address with no
>> command. If it works that way when a command is given on the same
>> line, that's a bug that needs fixing.
> There is no bug, and it is working correctly in the way you
> described. To avoid potential misunderstandings in t
On Thu, 14 Jan 2021, nia wrote:
On Thu, Jan 14, 2021 at 09:43:44PM +, RVP wrote:
Is this OK (or, it is hopelessly insecure)?:
If you have the same secure randomness as everyone else you don't have
secure randomness.
True, generally, but I was thinking of a) the hopeless cases, b) the
w
On Fri, Jan 15, 2021 at 12:21:24AM +, Taylor R Campbell wrote:
>
> What about them? Systems without usable microphone noise are no worse
> off than they would have been without nia's suggestion.
>
If we have network of some sort can we leverage packet timing jitter somehow?
--
Brett Lymn
> Date: Thu, 14 Jan 2021 13:21:58 +0100
> From: Manuel Bouyer
>
> On Thu, Jan 14, 2021 at 10:15:41AM +, nia wrote:
> > I still think my idea to record a second of noise from /dev/audio on
> > machines that totally lack other strong sources is a good one. We did
> > already put together the co
> Date: Thu, 14 Jan 2021 10:15:41 +
> From: nia
>
> I still think my idea to record a second of noise from /dev/audio on
> machines that totally lack other strong sources is a good one. We did
> already put together the code and test it on a range of hardware and
> VMs.
I agree -- I think sy
>That should be true only if you specify a listening address with no
>command. If it works that way when a command is given on the same
>line, that's a bug that needs fixing. (I feel moderately authoritative
>on this matter since I'm the person who added the code back in 1996.)
Our apologies. Th
On Thu, 14 Jan 2021, Manuel Bouyer wrote:
And what about systems that don't have a /dev/audio (or system that have
play-only /dev/audio) ?
Is this OK (or, it is hopelessly insecure)?:
1. Use environment (keyb. delay, mouse, ...) to seed the libc PRNG.
2. Use the PRNG values to pick out rand
> Date: Mon, 11 Jan 2021 12:23:46 +0100
> From: Martin Husemann
>
> On Mon, Jan 11, 2021 at 01:25:36AM +, Taylor R Campbell wrote:
> > We might also do something similar with the motd -- add a single line,
> > citing entropy(7) for more details, if there's not enough entropy.
>
> Please don'
On Thu, Jan 14, 2021 at 09:43:44PM +, RVP wrote:
> Is this OK (or, it is hopelessly insecure)?:
If you have the same secure randomness as everyone else you don't have
secure randomness.
If you do have unique secure randomness, you only need 256 bits of it
to continue generating it forever.
>
On Thu, Jan 14, 2021 at 04:41:18PM +0100, Hauke Fath wrote:
> Hi,
>
> I am looking at augmenting the linux-style 'shadow' map generation in
> /var/yp/Makefile.yp.
>
> In this context:
>
> (1) The 'change' field in master.passwd can either be empty[*] (no passwd
> aging), hold a maximum passwd ag
Hi,
I am looking at augmenting the linux-style 'shadow' map generation in
/var/yp/Makefile.yp.
In this context:
(1) The 'change' field in master.passwd can either be empty[*] (no
passwd aging), hold a maximum passwd age, or hold '-1', forcing the user
to set a new password during their next
>> inetd.conf already supports per-service overriding of the
>> listen-addr. According to cvsweb, this went in 1996-12-30 (inetd.8
>> rev 1.8, inetd.c rev 1.16).
> Itâ??s true that inetd currently supports specification of the
> listen-addr, however, the way it currently functions is that when
> [
On Thu, Jan 14, 2021 at 12:21:14PM -0800, James Browning wrote:
>
> Our reasoning behind not wanting multiple levels of includedir was to avoid
> overly complex or messy configuration systems, but we see your point. If time
> allows, then we will implement cycle detection.
>
If people want to sh
>That's not the only use for escapes. From a theoretical and aesthetic
>perspective, it would be nice to be able to get arbitrary octet
>sequences into arguments; as outlined, for example, it's not possible
>to get a newline into an argument. (Well, _almost_ arbitrary octet
>sequences. Until and
On Jan 14, 7:46, Mouse wrote:
}
} > The standard is explicit that the argument must be EOF or an unsigned
} > char. There is no way to support both true 8bit locales and
} > magically fix this.
}
} No way for ctype.h to do so independent of the rest of the system. But
} it's not at all hard to
In article <20210114111428.ga1...@antioche.eu.org>,
Manuel Bouyer wrote:
>Hello,
>In xentools, we have patches like
>-if (tolower(*s) != tolower(*se))
>+if (tolower((unsigned char)*s) != tolower((unsigned char)*se))
>
>(s and se being char*)
>
>This is to fix «array subscr
Date:Thu, 14 Jan 2021 10:54:45 -0500 (EST)
From:Mouse
Message-ID: <202101141554.kaa18...@stone.rodents-montreal.org>
| I don't have any POSIX reference
POSIX says the same thing you quoted for X99 about EOF (int with a negative
value) - which is no big surprise, f
>> [Y]ou just need to choose a value for EOF that is out of range for
>> signed char.
> I recall there being some debate about whether it's actually legal
> for EOF to have any value other than -1.
Curious. Do you recall the basis for such a position?
I don't have any POSIX reference, and my C r
On Thu, Jan 14, 2021 at 07:46:01AM -0500, Mouse wrote:
> > The standard is explicit that the argument must be EOF or an unsigned
> > char. There is no way to support both true 8bit locales and
> > magically fix this.
>
> No way for ctype.h to do so independent of the rest of the system. But
> The standard is explicit that the argument must be EOF or an unsigned
> char. There is no way to support both true 8bit locales and
> magically fix this.
No way for ctype.h to do so independent of the rest of the system. But
it's not at all hard to fix it from a libc design perspective; you ju
> In all cases the argument is an int, the value of which shall be
> representable as an unsigned char or shall equal the value of the
> macro EOF.
Which, if you think about it, makes sense. Otherwise, if EOF's value
is in range for signed char, that argument value would be ambiguous -
and EOF is
On Thu, Jan 14, 2021 at 12:28:57PM +0100, Manuel Bouyer wrote:
> On Thu, Jan 14, 2021 at 12:19:39PM +0100, Martin Husemann wrote:
> > On Thu, Jan 14, 2021 at 12:14:28PM +0100, Manuel Bouyer wrote:
> > > Any comment about this ? I'm not familiar with these details ...
> >
> > man ctype and search f
On Thu, Jan 14, 2021 at 12:52:06PM +0100, Martin Husemann wrote:
> On Thu, Jan 14, 2021 at 12:28:57PM +0100, Manuel Bouyer wrote:
> > Does the standard explicitely state that the value should either be
> > EOF or >= 0 ?
>
> Yes, Section 7.4 paragrah 1 second sentence (ISO C 2018):
>
> > In all ca
On Thu, Jan 14, 2021 at 10:15:41AM +, nia wrote:
> [...]
> I still think my idea to record a second of noise from /dev/audio on
> machines that totally lack other strong sources is a good one. We did
> already put together the code and test it on a range of hardware and
> VMs.
And what about s
On Thu, Jan 14, 2021 at 12:28:57PM +0100, Manuel Bouyer wrote:
> Does the standard explicitely state that the value should either be
> EOF or >= 0 ?
Yes, Section 7.4 paragrah 1 second sentence (ISO C 2018):
> In all cases the argument is an int, the value of which shall be
> representable as an u
On Thu, Jan 14, 2021 at 12:19:39PM +0100, Martin Husemann wrote:
> On Thu, Jan 14, 2021 at 12:14:28PM +0100, Manuel Bouyer wrote:
> > Any comment about this ? I'm not familiar with these details ...
>
> man ctype and search for CAVEATS
thanks.
So NetBSD and glibc took different approach to try to
On Thu, Jan 14, 2021 at 12:14:28PM +0100, Manuel Bouyer wrote:
> Any comment about this ? I'm not familiar with these details ...
man ctype and search for CAVEATS
Martin
Hello,
In xentools, we have patches like
-if (tolower(*s) != tolower(*se))
+if (tolower((unsigned char)*s) != tolower((unsigned char)*se))
(s and se being char*)
This is to fix «array subscript has type 'char' [-Werror=char-subscripts]»
I submitted this to Xen, and a deve
On Thu, Jan 14, 2021 at 10:15:41AM +, nia wrote:
> I don't think more options should be added to the installer (it has
> too many things that are confusing to a new user already),
This is the thinking that gets us to fully automated no choice tools
like the auto resizing usb images that I find
On Mon, Jan 11, 2021 at 12:23:46PM +0100, Martin Husemann wrote:
> I still think that this should be dealt with (once and for all) at
> installation time (as we did for a short period, for some machines and
> install methods) - but apparently it is impossible to reach consensus
> on the wording and
30 matches
Mail list logo
