On Fri, Mar 06 2020, "Theo de Raadt" wrote:
>> Jeremie Courreges-Anglas wrote:
>> >
>> >
>> > Checking the return value of fprintf is good but not enough to ensure
>> > that data has properly been written to the file without an error. To do
>> > that we can use fflush(3) in a single place.
[re
On Fri, Mar 06, 2020 at 11:29:57PM +, Stuart Henderson wrote:
> I've finally managed to get openbsd installed on an rpi3b (need
> something to run signify/pkg_sign and this is what I have). Thought I'd
> write up the install method because there are no useful docs at the
> moment and it's a bit
Thanks for your write-up, Stuart!
I just wanted to add that people can get it working on the RPi 3B+ with
some extra work:
- Put the package sets on the installation drive since network access
doesn't exist by default as you pointed out.
- Buy a supported USB network interface. I've used a wir
On 2020/03/06 23:29, Stuart Henderson wrote:
> (need
> something to run signify/pkg_sign and this is what I have).
oh, that's not going to work anyway. seabios still needs gcc/ld.bfd
(and I guess cross-compiling is going to be a pain).
I've finally managed to get openbsd installed on an rpi3b (need
something to run signify/pkg_sign and this is what I have). Thought I'd
write up the install method because there are no useful docs at the
moment and it's a bit fiddly. (Note that only rpi3b works - 3b+ has no
network/usb, the 32-bit
On Sun, Mar 1, 2020 at 10:41 PM YASUOKA Masahiko wrote:
>
> Hi,
>
> The problems you are pointing seem to be the same problem.
>
> > I'll try to test this diff next week if I can schedule some downtime.
>
> Test is appreciated.
>
> Also I'd like to know the result of
>
> hexdump -C /var/db/acpi/
On Fri, Mar 06, 2020 at 06:51:16PM +0100, Sebastian Benoit wrote:
> I dont see that here.
> Sure that you have an up-to-date tree?
> And no diff in there?
I think the problem is big-endian vs little-endian.
I need to think about how and if this should be fixed.
> Klemens Nanni(k...@openbsd.org)
Hi,
sorry, I simply forgot ldap_auth_sasl.
LDAP_OTHER is a good return code for imsg failure and I really like the
idea of using the LDAP return codes right away instead of the extra
mapping.
Your patch however doesn't work for SASL authentication (and
ldapsearch gives some strange messages), b
Oh you want to reach the error-reporting code...
> How about checking the return value of fclose() in output_finish() instead?
>
> Jeremie Courreges-Anglas wrote:
> >
> >
> > Checking the return value of fprintf is good but not enough to ensure
> > that data has properly been written to the fi
How about checking the return value of fclose() in output_finish() instead?
Jeremie Courreges-Anglas wrote:
>
>
> Checking the return value of fprintf is good but not enough to ensure
> that data has properly been written to the file without an error. To do
> that we can use fflush(3) in a sin
Checking the return value of fprintf is good but not enough to ensure
that data has properly been written to the file without an error. To do
that we can use fflush(3) in a single place.
Build-tested only. ok?
Bonus: in output_finish(), "out = NULL;" is pointless, so zap it.
I suspect it's a
On Fri, Mar 06 2020, Sebastian Benoit wrote:
> Job Snijders(j...@openbsd.org) on 2020.03.06 17:31:13 +:
>> I have a small suggestion, in some deployments I saw the convention to
>> name it as following so it is clear the data came from user provided
>> data rather than internal bird structures
On Fri, Mar 06, 2020 at 06:51:16PM +0100, Sebastian Benoit wrote:
> I dont see that here.
> Sure that you have an up-to-date tree?
> And no diff in there?
I run regress on sparc64 with a -CURRENT /usr/src tree; latest bgpd is
installed from source, but the machine is currently running a snapshot
f
On Fri, Mar 06, 2020 at 07:11:56PM +0100, Robert Scheck wrote:
> On Fri, 06 Mar 2020, Sebastian Benoit wrote:
> > Note that I haven't tried this with bird 1 or 2 yet ;)
> > comments, oks?
>
> I did not try it yet, but I think BIRD 1 also needs something like "define
> force_roa_table_update = %lld
On Fri, 06 Mar 2020, Sebastian Benoit wrote:
> Note that I haven't tried this with bird 1 or 2 yet ;)
> comments, oks?
I did not try it yet, but I think BIRD 1 also needs something like "define
force_roa_table_update = %lld;" and maybe some table definition. I will try
BIRD 1 and 2 during the week
I dont see that here.
Sure that you have an up-to-date tree?
And no diff in there?
Klemens Nanni(k...@openbsd.org) on 2020.03.05 23:39:20 +0100:
>
> I ran bgpd to test diffs and stumbled across what looks like simple
> disorder in the config checks.
>
> bgpd must have changed in how it orders a
Robert Scheck(rob...@fedoraproject.org) on 2020.03.06 14:02:26 +0100:
> On Fri, 06 Mar 2020, Job Snijders wrote:
> > I believe Robert is referring to this snippet of code:
> >
> >
> > https://patch-diff.githubusercontent.com/raw/kristapsdz/rpki-client/pull/21.patch
Thanks for the patch.
I co
Job Snijders(j...@openbsd.org) on 2020.03.06 17:31:13 +:
> I have a small suggestion, in some deployments I saw the convention to
> name it as following so it is clear the data came from user provided
> data rather than internal bird structures
>
> I tested Benno's patch against BIRD 1.6.6 -
I have a small suggestion, in some deployments I saw the convention to
name it as following so it is clear the data came from user provided
data rather than internal bird structures
I tested Benno's patch against BIRD 1.6.6 - wfm.
Index: main.c
===
On Fri, Mar 06, 2020 at 05:53:59PM +0100, Sebastian Benoit wrote:
> Hi,
>
> generate 3 different outputs for BIRD:
> - bird v1 with IPv4 routes
> - bird v1 with IPv6 routes
> - bird v2
> when using command line option -B.
> BIRD v2 output from Robert Scheck, robert AT fedoraproject DOT org
>
>
>
Hi,
generate 3 different outputs for BIRD:
- bird v1 with IPv4 routes
- bird v1 with IPv6 routes
- bird v2
when using command line option -B.
BIRD v2 output from Robert Scheck, robert AT fedoraproject DOT org
Note that I haven't tried this with bird 1 or 2 yet ;)
comments, oks?
(benno_rpki_bir
OK deraadt, sort of.
While I'm here I'd like to point out that a hilarious discussion in
regards to glibc's 64-bit time_t support, which is adding manual pads
the middle of standardized structs leading to mis-initialization.
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#struct_timespec
Hi,
if timeout_initialized() returns 0, enqueue_randomness() may use 'ts'
uninitialized. This is not really a problem because the value is
blended with other collected entropy. To make things clearer
I would still prefer to always initialize 'ts'.
ok?
Index: rnd.c
=
On Fri, Mar 06 2020, Sebastian Benoit wrote:
> Robert Scheck(rob...@fedoraproject.org) on 2020.03.06 14:02:26 +0100:
>> On Fri, 06 Mar 2020, Job Snijders wrote:
>> > I believe Robert is referring to this snippet of code:
>> >
>> >
>> > https://patch-diff.githubusercontent.com/raw/kristapsdz/
Robert Scheck(rob...@fedoraproject.org) on 2020.03.06 14:02:26 +0100:
> On Fri, 06 Mar 2020, Job Snijders wrote:
> > I believe Robert is referring to this snippet of code:
> >
> >
> > https://patch-diff.githubusercontent.com/raw/kristapsdz/rpki-client/pull/21.patch
>
> Exactly.
Ah, i though
On Fri, 06 Mar 2020, Job Snijders wrote:
> I believe Robert is referring to this snippet of code:
>
>
> https://patch-diff.githubusercontent.com/raw/kristapsdz/rpki-client/pull/21.patch
Exactly.
Regards,
Robert
On Fri, Mar 06, 2020 at 12:24:18PM +0100, Sebastian Benoit wrote:
> Robert Scheck(rob...@fedoraproject.org) on 2020.03.03 01:20:24 +0100:
> > job@ suggested to move this from GitHub to tech@ list (as upstream):
> >
> > 1. Currently, BIRD 1.x support in rpki-client seems to be broken: As per
> >
Hello,
I was using base gcc but switching to base clang fixes the warnings on
-current at least.
Is base gcc not supported anymore ?
Sorry for the noise.
Cheers,
Le jeu. 5 mars 2020 à 16:59, Theo de Raadt a écrit :
>
> Todd C. Miller wrote:
>
> > On Thu, 05 Mar 2020 16:07:48 +0100, Thomas de
Robert Scheck(rob...@fedoraproject.org) on 2020.03.03 01:20:24 +0100:
> Hi,
>
> job@ suggested to move this from GitHub to tech@ list (as upstream):
>
> 1. Currently, BIRD 1.x support in rpki-client seems to be broken: As per
>BIRD upstream the "combined format" produced by rpki-client can't
On Fri, Mar 06, 2020 at 10:47:44AM +0100, Stefan Sperling wrote:
> 802.11 frame sequence numbers are in the range 0x0 - 0xfff.
>
> Don't let internal representations of sequence numbers grow beyond 0xfff.
>
> ok?
>
> diff 582540bcd55abf4efa3abe8c23ebc7f3c247245d
> ba499e0f51b139f9ad6d4b4ea1
802.11 frame sequence numbers are in the range 0x0 - 0xfff.
Don't let internal representations of sequence numbers grow beyond 0xfff.
ok?
diff 582540bcd55abf4efa3abe8c23ebc7f3c247245d
ba499e0f51b139f9ad6d4b4ea18cbf56bd93
blob - 808b6e1f46b777ea408561c0fbf511e79d477c54
blob + 6c8057426973640
31 matches
Mail list logo
