> On Thu, Dec 11, 2014 at 09:52:46PM -0800, Eugene Yunak wrote:
> > Thank you. Are there any specific good libraries you know of?
>
>
> LibreSSL :-)
Indeed, if a system has LibreSSL, you will find the arc4random
family in -lcrypto.
On Thu, Dec 11, 2014 at 09:52:46PM -0800, Eugene Yunak wrote:
> Thank you. Are there any specific good libraries you know of?
>
>
> --
> The best the little guy can do is what
> the little guy does right
LibreSSL :-)
-Bryan.
> > There are libraries available which provide arc4random() on Linux, so
> > maybe you find an upstream software provider who is willing to create
> > a dependency on such a library on Linux.
> >
> > Lots of software is doing precisely that, so don't be afraid.
> >
> >
> Thank you. Are there any s
On 11 December 2014 at 21:43, Theo de Raadt wrote:
>
> > On 12 Dec 2014, at 5:02, Theo de Raadt wrote:
> >
> > > In all of these code blocks are a well-known piece of information
> > > (same time on your machine as everywhere else) is being used to seed a
> > > deterministic number generator.
> >
On 12 Dec 2014, at 5:43, Theo de Raadt wrote:
>> On 12 Dec 2014, at 5:02, Theo de Raadt wrote:
>>
>>> In all of these code blocks are a well-known piece of information
>>> (same time on your machine as everywhere else) is being used to seed a
>>> deterministic number generator.
>>>
>>> At some lat
> On 12 Dec 2014, at 5:02, Theo de Raadt wrote:
>
> > In all of these code blocks are a well-known piece of information
> > (same time on your machine as everywhere else) is being used to seed a
> > deterministic number generator.
> >
> > At some later point, deterministic numbers are taken out us
On 12 Dec 2014, at 5:02, Theo de Raadt wrote:
In all of these code blocks are a well-known piece of information
(same time on your machine as everywhere else) is being used to seed a
deterministic number generator.
At some later point, deterministic numbers are taken out using rand(),
random(),
In all of these code blocks are a well-known piece of information
(same time on your machine as everywhere else) is being used to seed a
deterministic number generator.
At some later point, deterministic numbers are taken out using rand(),
random(), drand48(), lrand48(), mrand48(), or srand48(), o
Has anyone given any thought to the impact of 1300+ software
packages using the practice of
srand(time(NULL));
in an increasingly NTP-syncronized world?
>From the code I've been reading, I am certain some folk have looked
into it.
First, I think the BatteryPresent check has a signedness problem. Second, I
think that it should check for sensor validity too, so it doesn’t use stale
values if BatteryPresent somehow goes straight from present to invalid.
This diff should fix both things, in theory. Compiled and running with
Now that my upd(4) is working (thanks to all involved), I’m looking to improve
behavior a bit. Let’s add some state transitions to the sensors.
Feedback is welcome.
--david
## before
[vm@vm usb]$ sysctl hw.sensors.upd0
hw.sensors.upd0.indicator0=Off (Charging), OK
hw.sensors.upd0.indicator1=O
I'm wondering what reception this will get. It feeds TCP/UDP port
numbers into the hash for trunk(4) load balancing, so connections
between a single pair of hosts will get distributed across NICs.
Taken from FreeBSD r232629, they also added SIOC[CS]LAGGHASH ioctls
so that the hash type can be confi
> > From: Alexey Suslikov
> > Date: Thu, 11 Dec 2014 20:51:14 + (UTC)
> >
> > Stefan Fritsch sfritsch.de> writes:
> >
> > > --- a/sys/arch/amd64/include/specialreg.h
> > > +++ b/sys/arch/amd64/include/specialreg.h
> > > -158,6 +158,7
> > > #define CPUIDECX_AVX0x1000
> From: Alexey Suslikov
> Date: Thu, 11 Dec 2014 20:51:14 + (UTC)
>
> Stefan Fritsch sfritsch.de> writes:
>
> > --- a/sys/arch/amd64/include/specialreg.h
> > +++ b/sys/arch/amd64/include/specialreg.h
> > -158,6 +158,7
> > #defineCPUIDECX_AVX0x1000 /* Advanced Vec
Stefan Fritsch sfritsch.de> writes:
> --- a/sys/arch/amd64/include/specialreg.h
> +++ b/sys/arch/amd64/include/specialreg.h
> -158,6 +158,7
> #define CPUIDECX_AVX0x1000 /* Advanced Vector Extensions
*/
> #define CPUIDECX_F16C 0x2000 /* 16bit fp conve
On Thu, Dec 11, 2014 at 08:21:12PM +, Miod Vallat wrote:
> > Hi,
> >
> > I'm encountering system crash during boot with latest snapshot. Turns
> > out that it works fine when I disable skgpio through UKC.
>
> Try this.
Okay tobias@, too. ;)
The system boots nicely again, thanks!
> Hi,
>
> I'm encountering system crash during boot with latest snapshot. Turns
> out that it works fine when I disable skgpio through UKC.
Try this.
Index: skgpio.c
===
RCS file: /cvs/src/sys/dev/isa/skgpio.c,v
retrieving revision
Hi,
I'm encountering system crash during boot with latest snapshot. Turns
out that it works fine when I disable skgpio through UKC.
Have no serial console on this system so I copied this by typing it down
on my second system... Guess it has the most important parts in it:
[...]
npx0 at isa0 po
On Thursday 11 December 2014 22:20:06, Jonathan Gray wrote:
> On Wed, Dec 10, 2014 at 12:32:02AM +0100, Stefan Fritsch wrote:
> > For the codepatching part, the most interesting files are
> > codepatch.c and codepatch.h. In copy.S and cpu.c, I convert the
> > code patching already done for SMAP to
On Thu, Dec 11, 2014 at 6:22 AM, Martin Pieuchot wrote:
> Thanks for all your comments. I though a bit more about this change and
> decided to:
>
> - Simply return the number of bytes written/read upon success and -1
> otherwise (à la read/write). This allows us to remove some usages
>
> From: Bob Beck
> Date: Thu, 11 Dec 2014 08:39:15 -0700
>
> i.e. if we want the "openssl" command to report someting specific we
> put it in there, not a globally visible string that will be used for
> the wrong things.
I think you guys are trying to hard to prevent people to shoot
themselves i
On 11 December 2014 at 14:16, Martin Pieuchot wrote:
> On 11/12/14(Thu) 12:37, frantisek holop wrote:
>> > > login: kernel: page fault trap, code=0
>> > > Stopped at in_selectsrc+0xd8: movl 0xf0(%esi),%ebx
>> > > ddb{0}> trace
>> > > in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfa
i.e. if we want the "openssl" command to report someting specific we
put it in there, not a globally visible string that will be used for
the wrong things.
On Thu, Dec 11, 2014 at 8:37 AM, Bob Beck wrote:
> likely whatever we change it to print. but we should catch that.
>
> On Thu, Dec 11, 2014
likely whatever we change it to print. but we should catch that.
On Thu, Dec 11, 2014 at 8:34 AM, Mark Kettenis wrote:
>> Date: Thu, 11 Dec 2014 08:15:06 -0600
>> From: Brent Cook
>>
>> To reduce reliance on this string, and to make it more consistently
>> correct between LibreSSL-portable rele
Absolutely yes.
On Thu, Dec 11, 2014 at 7:15 AM, Brent Cook wrote:
> To reduce reliance on this string, and to make it more consistently
> correct between LibreSSL-portable releases, reduce OPENSSL_VERSION_TEXT
> to say the bare minimum.
>
> There are better, more portable and consistent mechanis
> Date: Thu, 11 Dec 2014 08:15:06 -0600
> From: Brent Cook
>
> To reduce reliance on this string, and to make it more consistently
> correct between LibreSSL-portable releases, reduce OPENSSL_VERSION_TEXT
> to say the bare minimum.
>
> There are better, more portable and consistent mechanisms fo
On Thu, Dec 11, 2014 at 6:51 AM, Stuart Henderson wrote:
> On 2014/12/11 16:42, Dmitry Eremin-Solenikov wrote:
>> 2014-12-11 15:40 GMT+03:00 Stuart Henderson :
>> > On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
>> >> Hello,
>> >>
>> >> For the historic reasons there is a significant amount o
On Thu, Dec 11, 2014 at 02:31:32PM +, Jason McIntyre wrote:
> fixed, but couple of comments inline:
OK, thanks for corrections, will keep in mind.
On Wed, Dec 10, 2014 at 12:21:21PM +0200, Kaspars Bankovskis wrote:
> Index: vfs_bio.c
> ===
> RCS file: /cvs/src/sys/kern/vfs_bio.c,v
> retrieving revision 1.163
> diff -u -p -r1.163 vfs_bio.c
> --- vfs_bio.c 8 Oct 2014 07:33:14 -
On Wed, Dec 10, 2014 at 06:15:04PM +0200, Kaspars Bankovskis wrote:
> allocbuf was removed in 1.88 of sys/kern/vfs_bio.c
>
> but not from manpages
>
fixed, but couple of comments inline:
> Index: distrib/sets/lists/comp/mi
> ===
>
To reduce reliance on this string, and to make it more consistently
correct between LibreSSL-portable releases, reduce OPENSSL_VERSION_TEXT
to say the bare minimum.
There are better, more portable and consistent mechanisms for
determining the installed versions of packages, such as the OS package
Short answer Dmitry: No.
Doing so doesn't solve a real problem, and creates many others. Sure
we might not like it ourselves and would never build new software this
way, but removing this legacy at this stage would only break things
for no benefit. (We're very happy to break things when there is
Previously, they were all using the portable package version, rather
than the individual library versions. openssl(1)'s pc file represents
the LibreSSL-portable release however.
$ pkg-config --modversion libtls
1:0:0
$ pkg-config --modversion openssl
2.1.2
$ pkg-config --modversion libssl
30:0:0
$
On Thu, Dec 11, 2014 at 6:41 AM, Lukas Tribus wrote:
>>> Many Lolz.. Lukas you just made my day..
>>>
>>> They've been misused that way, and more than once, by more than one
>>> project. This is why we really want it to be just a string, and
>>> strongly discourage people from using it in the
On 11/12/14(Thu) 12:37, frantisek holop wrote:
> > > login: kernel: page fault trap, code=0
> > > Stopped at in_selectsrc+0xd8: movl 0xf0(%esi),%ebx
> > > ddb{0}> trace
> > > in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfac34) at
> > > in_selectsrc+0xd8
> > >
> > > udp_output(d8c
Hi all,
I've just noticed one more page in need of 5.5 -> 5.6 update - diff
below.
Regards,
Raf
Index: www/stable.html
===
RCS file: /cvs/www/stable.html,v
retrieving revision 1.36
diff -u -p -r1.36 stable.html
--- www/stable.html
On 2014/12/11 16:42, Dmitry Eremin-Solenikov wrote:
> 2014-12-11 15:40 GMT+03:00 Stuart Henderson :
> > On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
> >> Hello,
> >>
> >> For the historic reasons there is a significant amount of duplicated
> >> functionality.
> >> For example one can use ope
On 2014/12/11 07:41, sven falempin wrote:
> Thank you all,
>
> I grep(ed) -r NCT6 in sys and didn't find wbsio, I guess those
> christmass holydays will be much welcome !
>
> Does the wbsio detect the watchdog in the apu card ?
No, as the manual says, "Only the hardware monitoring function is
cu
2014-12-11 15:40 GMT+03:00 Stuart Henderson :
> On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
>> Hello,
>>
>> For the historic reasons there is a significant amount of duplicated
>> functionality.
>> For example one can use openssl rsa/dsa/ec to create/modify private/public
>> keys
>> or it'
Thank you all,
I grep(ed) -r NCT6 in sys and didn't find wbsio, I guess those
christmass holydays will be much welcome !
Does the wbsio detect the watchdog in the apu card ?
On Thu, Dec 11, 2014 at 5:56 AM, Mark Kettenis wrote:
>> Date: Thu, 11 Dec 2014 05:08:11 -0500
>> From: Matt Dainty
>>
>
>> Many Lolz.. Lukas you just made my day..
>>
>> They've been misused that way, and more than once, by more than one
>> project. This is why we really want it to be just a string, and
>> strongly discourage people from using it in the way it has been
>> abused.
>>
>> ... we could always change
On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
> Hello,
>
> For the historic reasons there is a significant amount of duplicated
> functionality.
> For example one can use openssl rsa/dsa/ec to create/modify private/public
> keys
> or it's possible to just use a generic openssl genpkey/pkey
On 11/12/14(Thu) 12:48, Mark Kettenis wrote:
> > Date: Thu, 11 Dec 2014 12:22:56 +0100
> > From: Martin Pieuchot
> >
> > Index: ucycom.c
> > ===
> > RCS file: /home/ncvs/src/sys/dev/usb/ucycom.c,v
> > retrieving revision 1.29
> > dif
Hello,
For the historic reasons there is a significant amount of duplicated
functionality.
For example one can use openssl rsa/dsa/ec to create/modify private/public keys
or it's possible to just use a generic openssl genpkey/pkey interface. I'd like
to suggest to clean up the first set of command
> Date: Thu, 11 Dec 2014 12:22:56 +0100
> From: Martin Pieuchot
>
> Index: ucycom.c
> ===
> RCS file: /home/ncvs/src/sys/dev/usb/ucycom.c,v
> retrieving revision 1.29
> diff -u -p -r1.29 ucycom.c
> --- ucycom.c 12 Jul 2014 20:26:33
On 09/12/14(Tue) 10:57, David Higgs wrote:
> On Dec 8, 2014, at 6:07 PM, Martin Pieuchot wrote:
>
> > On 08/12/14(Mon) 09:35, David Higgs wrote:
> >> On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot
> >> wrote:
> >> [...]
> >>> Now I'd like to finish the transition that started with the import o
Martin Pieuchot, 11 Dec 2014 11:59:
> On 11/12/14(Thu) 11:31, frantisek holop wrote:
> > i think this page fault is triggered by jenkins
> > during resume.
> > login: kernel: page fault trap, code=0
> > Stopped at in_selectsrc+0xd8: movl 0xf0(%esi),%ebx
> > ddb{0}> trace
> > in_selectsrc(
On Wed, Dec 10, 2014 at 12:32:02AM +0100, Stefan Fritsch wrote:
> Hi,
>
> in summer, I posted some paravirt patches for amd64. In response to the
> comments I received then, I have created some infrastructure to binary
> patch kernel code during boot. In order to get some feedback, I am posting
On 11/12/14(Thu) 11:31, frantisek holop wrote:
> i think this page fault is triggered by jenkins
> during resume.
> login: kernel: page fault trap, code=0
> Stopped at in_selectsrc+0xd8: movl 0xf0(%esi),%ebx
> ddb{0}> trace
> in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfac34) at
> Date: Thu, 11 Dec 2014 05:08:11 -0500
> From: Matt Dainty
>
> * sven falempin [2014-12-10 12:32:15]:
> > On Wed, Dec 10, 2014 at 9:31 AM, Stuart Henderson wrote:
> > > On 2014/12/10 09:15, sven falempin wrote:
> > >> http://lxr.free-electrons.com/source/drivers/hwmon/nct6775.c
> > >>
> > >> h
i think this page fault is triggered by jenkins
during resume.
login: kernel: page fault trap, code=0
Stopped at in_selectsrc+0xd8: movl 0xf0(%esi),%ebx
ddb{0}> trace
in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfac34) at in_selectsrc+0xd8
udp_output(d8cfabfc,d80b6900,d80b6700,0
* sven falempin [2014-12-10 12:32:15]:
> On Wed, Dec 10, 2014 at 9:31 AM, Stuart Henderson wrote:
> > On 2014/12/10 09:15, sven falempin wrote:
> >> http://lxr.free-electrons.com/source/drivers/hwmon/nct6775.c
> >>
> >> https://github.com/groeck/nct6775
> >>
> >> So i guess the first step is to d
52 matches
Mail list logo
