r now, I'm doing a local patch to always check char3. This is
probably suboptimal yet I cannot see a better solution for this
specific issue. Does any of you have a better idea?
Best regards,
-- Emmanuel Deloget
___
busybox mailing list
busybox@bu
Hello,
On Fri, Mar 3, 2017 at 1:44 PM, Tito wrote:
>
>
> On 03/03/2017 01:01 PM, Emmanuel Deloget wrote:
>>
>> Hello,
>>
>> I'm using BB 1.26.2 with an heavily modified LEDE where I added
>> procps-ng and sysvinit. Given that setup, I'm using
Hi,
On Fri, Mar 3, 2017 at 3:17 PM, Kang-Che Sung wrote:
> On 03/03/2017 01:01 PM, Emmanuel Deloget wrote:
>>
>> Hello,
>>
>> I'm using BB 1.26.2 with an heavily modified LEDE where I added
>> procps-ng and sysvinit. Given that setup, I'm using /usr/
ring to lsusb
instead of lsscsi.
>
> >> BR,
> >> //Markus - The panama-hat hacker
> >>
Best regards,
-- Emmanuel Deloget
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
95
> should I add a comment to the affect we're assuming PATH_MAX is at
> least 4096? Maybe a check is also needed?
>
Alternatively you may use the m modifier, when implemented, to
auto-allocate the name pointer. This way you don't have to hardcode
anything in the ss
be an instance of the bug
(according to the bug report, it's no longer reproducible in GCC
trunk).
Anyway, it might be a good idea to avoid unsetting the warning for one
buggy GCC version :)
Best regards,
-- Emmanuel Deloget
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593
[2] ht
dian0() which in turn takes an
> `uint32_t *` as first parameter. And that's where the type-punning is
> broken.
>
>
This would be quite weird - the static function is by definition local to
the compilation unit, and the compiler cannot know about the content of
decompress_unxz.c from xz_dec_stream.c.
BR,
-- Emmanuel Deloget
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
On Mon, Aug 7, 2017 at 10:37 PM, Emmanuel Deloget wrote:
>
>
>
> On Mon, Aug 7, 2017 at 9:46 PM, Johannes Schindelin
> wrote:
>>
>> Hi Denys,
>>
>> On Mon, 7 Aug 2017, Denys Vlasenko wrote:
>>
>> > On Mon, Aug 7, 2017 at 12:09 PM,
Hi Johannes
On Tue, Aug 8, 2017 at 1:19 PM, Johannes Schindelin <
johannes.schinde...@gmx.de> wrote:
> Hi Emmanuel,
>
> On Mon, 7 Aug 2017, Emmanuel Deloget wrote:
>
> > And yes, its seems that the get_le32() macro in xz_private.h is a bit
> > illegal with respect t
e the GNU counterpart implements both
forward and backward regex search). I can submit that if the community
is interested.
BR,
-- Emmanuel Deloget
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
unsvdir dies, the children are reparented to /bin/init which
is, AFAIK, reaping them.
I won't disagree with you (you say you have zombies all over the place) but
maybe the problem - and the right fix - lies somewhere else.
Best regards,
-- Emmanuel Deloget
_
children
> themselves of runsvdir.
>
Any process of pid 1 is expected to be the ultimate child reaper, so once
runsvdir dies its children are bound to be reaped by init. That's how unix
has worked for decades :)
BR,
-- Emmanuel Deloget
___
busybox
f the
delivered signal is SIGCHLD - unless you install a handler for this signal.
Since busybox' init does not do that, then no, sleep() will not be
interrupted in that case (and you face the problem Laurent describes).
>
> -- Jim
>
>
Best regards,
-- Emmanuel Deloget
[1] h
many (for instance, I) expect . and
source to behave the same way :) Having them behaving differently would
somewhat violate the principle of least surprise :)
BR,
-- Emmanuel Deloget
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
; long double can be very slow (emulated) and complex to support, which
> might not be of concern here though.
> But first and foremost nobody complained yet AFAIK.
> Maybe keep it as is? Actively reject values too large for plain double
> in printf(1) for now?
>
Hi Venkat,
But i didn't get where *timezone *is defined and what it is contained, Can
> you help us where it is defined and what it is contained.
>
timezone is defined in time.h and is documented in man 3 timezone.
Best regards,
-- Emman
) ? (char *)s : NULL;
> }
>
In favor of const-correctness, wouldn't it be better to return a const
char*? It's quite strange to promote a string to const and to a part
of it that is non-const (not to mention that if you feed the function
with a real const char* then the cast is not a good thing to do).
>
> > Fun to play with you.
> >
> > Cheers,
> >
> > Xabier Oneca_,,_
Best regards,
-- Emmanuel Deloget
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
ity of the generated HTML for a few
bytes.
Of course, you're free to ignore my opinion :)
Best regards,
-- Emmanuel Deloget
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
t; if (!argv[0]) /* "-p PRIO PID [...]" */
>
>
> I looked at it several times, but this looks not so good.
> These direct syscalls are less maintainable.
>
> OTOH... by the looks of it, there is no alternative?
Maybe define a function or even a static inline that does the job? That should
not cause any issue and it should be easier to maintain (not to mention that it
could be added to libbb if needed in order to be reused in other places).
On a side note, instead of checking for __linux__ only, one can also check for
!__GLIBC__ as well in order to limit the use case to libraries that are not the
glibc (yes, I link busybox with the glibc, which more or less defeat the
purpose of busybox).
#if defined(__linux__) && defined(SYS_sched_setscheduler) && !defined(__GLIBC__)
> I'll probably apply it.
Best regards,
-- Emmanuel Deloget
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Hello,
On Thu, Aug 12, 2021 at 4:01 PM Ron Yorston wrote:
>
> Roberto A. Foglietta wrote:
> >Hi Ron,
> >
> > what's about the other five?
>
* busybox-1.33.0_skip-loop-control.patch makes get_free_loop() behave
as if there was no free loop devices (unconditionnaly). It would help
to have some bac
identifier names).
[1] https://lists.gnu.org/archive/html/bug-bash/2018-11/msg00069.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799/
> --
> Roberto A. Foglietta
> +39.349.33.30.697
Best regards,
-- Emmanuel Deloget
___
busybox mailing lis
I'm not sure why it does ; maybe the
condition is not correct and we are not in the case where we always
get comm == "exe". I did not investigate that much.
Best regards,
-- Emmanuel Deloget
Le lun. 11 oct. 2021 à 14:24, a écrit :
>
> I forgot to mention that the issue isn'
Hello Tim,
it seems to me that it should not be that complicated, as the tar
handling code is mostly encapsulated into a library of its own.
See https://git.busybox.net/busybox/tree/archival/libarchive for
futher reference.
Best regards,
-- Emmanuel Deloget
Le jeu. 3 mars 2022 à 18:59, Tim
ing whether the random
pool in in a correct state (in which case I'm not sure you shall trust this
security-oriented process in the first place) the goal of seedrng is not
to protect all reads from /dev/urandom, but to make sure that we have
enough entropy to do the Real Work.
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
It seems to me that one might want to add a
CONFIG_FAVOR_SIZE_OVER_SECURITY configuration flag. I wish to say
that I'm not sure it's a good idea. Having a small busybox is a good thing, but
having a too small busybox that breaks products because of bad security
choices is not.
Best regards,
-- Emmanuel Deloget
[1]
https://github.com/systemd/systemd/blob/d9338387d94ad611233cf0753801eefccfda432a/src/udev/udev-watch.c#L102
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Le lun. 2 mai 2022 à 03:31, Denys Vlasenko a écrit :
>
> On Sun, May 1, 2022 at 6:35 PM Emmanuel Deloget wrote:
> > > > - RNG is seeded and credited using file A.
> > > > - File A is unlinked but not fsync()d.
> > > > - TLS connection does something
Hi,
Le lun. 2 mai 2022 à 11:37, Denys Vlasenko a écrit :
>
> On Mon, May 2, 2022 at 8:26 AM Emmanuel Deloget wrote:
> > Le lun. 2 mai 2022 à 03:31, Denys Vlasenko a
> > écrit :
> > > > I beg to differ, and especially on some embedded systems where the RNG
>
e the amount of time taken.
> +
> INSERT
>
> endmenu
> diff --git a/loginutils/chpasswd.c b/loginutils/chpasswd.c
> index a032abbed..74673fa6f 100644
> --- a/loginutils/chpasswd.c
> +++ b/loginutils/chpasswd.c
> @@ -17,7 +17,8 @@
> //config: default "des"
> //config: depends on PASSWD || CRYPTPW || CHPASSWD
> //config: help
> -//config: Possible choices are "d[es]", "m[d5]", "s[ha256]" or
> "sha512".
> +//config: Possible choices are "d[es]", "m[d5]", "s[ha256]",
> +//config: "sha512" or "b[crypt]" (when enabled).
> //applet:IF_CHPASSWD(APPLET(chpasswd, BB_DIR_USR_SBIN, BB_SUID_DROP))
>
> --
> 2.34.1
Best regards,
-- Emmanuel Deloget
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
27 matches
Mail list logo