On Fri, Dec 23, 2011 at 07:51:43PM +0200, Kostik Belousov wrote:
> The __FreeBSD_libc_enter_restricted_mode() is, and its name is ugly
> exactly to note the ugly intent. I do not see how the symbol can go
There must be no ugly intents and names. This whole idea just proves yet
one our @secteam ug
On Sat, Dec 24, 2011 at 02:26:20AM -0800, Xin LI wrote:
> chroot(2) can create legitimate and secure environment where dlopen(2)
> is safe and necessary.
Yes, so ischroot() check can be used only into that places where libc's
libc_dlopen() currently used, i.e. placed into libc_dlopen() itself.
-
On Sat, Dec 24, 2011 at 02:45:21AM -0800, Xin LI wrote:
> On Sat, Dec 24, 2011 at 2:39 AM, Andrey Chernov wrote:
> > On Sat, Dec 24, 2011 at 02:26:20AM -0800, Xin LI wrote:
> >> chroot(2) can create legitimate and secure environment where dlopen(2)
> >> is safe and
On Sat, Dec 24, 2011 at 02:50:45PM +0400, Andrey Chernov wrote:
> On Sat, Dec 24, 2011 at 02:45:21AM -0800, Xin LI wrote:
> > On Sat, Dec 24, 2011 at 2:39 AM, Andrey Chernov wrote:
> > > On Sat, Dec 24, 2011 at 02:26:20AM -0800, Xin LI wrote:
> > >> chroot(2) ca
On Wed, Sep 02, 2009 at 09:08:09AM +0200, Simon L. Nielsen wrote:
> > Log:
> > Use (unsigned char) cast for ctype macro
>
> Acording to the manual page and the C standard book I have, isdigit()
> takes an int for an argument, so why change this?
Not exactly that. From our manual page:
"The val
On Thu, Sep 03, 2009 at 09:26:03AM +0200, Dag-Erling Sm??rgrav wrote:
>
> - The core dump ache refers to can occur with a na??ve implementation
>that uses a lookup table and checks for EOF, but not for other
>negative values.
Thanx for detailed explanation. Just to note: even such naive
On Thu, Sep 03, 2009 at 11:08:26AM +0200, Dag-Erling Sm??rgrav wrote:
>
> What do you think of the attached patch?
Looks nice.
--
http://ache.pp.ru/
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsu
On Fri, Sep 04, 2009 at 01:42:04PM +1000, Bruce Evans wrote:
> The patch is missing the corresponding text for wctype functions
> (argmuments of type wint_t generally give undefined behaviour unless
> their value is representable as a wchar_t or equal to the value of
> WEOF). In FreeBSD, wint_t ha
On Fri, Sep 04, 2009 at 03:21:09PM +1000, Bruce Evans wrote:
> % The value of the argument must be representable as an
> % .Vt "unsigned char"
> % or the value of
> % .Dv EOF .
>
> This is the same as in POSIX except the POSIX wording is better (e.g.,
> the above only says implicitly that the beha
On Fri, Sep 04, 2009 at 12:32:14PM +0200, Ed Schouten wrote:
> Even though I really appreciate fixes/cleanups to ee(1), I think changes
> like these should be sent to its maintainer as well. Have you done this?
Yes.
--
http://ache.pp.ru/
pgpkzWA3ddeoN.pgp
Description: PGP signature
On Fri, Sep 04, 2009 at 04:50:05PM +0200, Ed Schouten wrote:
> * Andrey Chernov wrote:
> > On Fri, Sep 04, 2009 at 12:32:14PM +0200, Ed Schouten wrote:
> > > Even though I really appreciate fixes/cleanups to ee(1), I think changes
> > > like these should be sent to i
On Tue, Sep 08, 2009 at 03:55:13PM +, Roman Divacky wrote:
> + * Detect whether this is a text file. The correct way to
> + * do this is to check the least significant bit of the
> + * "internal file attributes" field of the corresponding
> +
On Wed, Sep 09, 2009 at 05:14:32PM +0200, Dag-Erling Sm??rgrav wrote:
> Andrey Chernov writes:
> > If I understand the purpose of this code right, better use
> > isalnum()+ispunct()+ispace()
> > combination to count non-ASCII people too.
>
> uh, isprint() perhaps?
I
On Wed, Sep 09, 2009 at 08:16:09AM -0700, Tim Kientzle wrote:
> Since this is only to support -a (which does end-of-line
> conversions), I would suggest using a rather different
> set of heuristics that examines end-of-line sequences
> and control characters only:
>* Any byte value <31 that's n
On Tue, Sep 27, 2011 at 03:57:13PM +, Dag-Erling Smorgrav wrote:
> Author: des
> Date: Tue Sep 27 15:57:13 2011
> New Revision: 225800
> URL: http://svn.freebsd.org/changeset/base/225800
>
> Log:
> Followup to r225599: the fseek() was a no-op since the file was opened
> in append mode. Op
On Fri, Oct 07, 2011 at 12:42:03PM +, Ed Schouten wrote:
> Author: ed
> Date: Fri Oct 7 12:42:03 2011
> New Revision: 226100
> URL: http://svn.freebsd.org/changeset/base/226100
>
> Log:
> Simply let teken_stress use arc4random.
>
> This makes it run quite a bit faster, since it makes s
On Sun, Oct 16, 2011 at 01:54:46PM +, Andre Oppermann wrote:
> Author: andre
> Date: Sun Oct 16 13:54:46 2011
> New Revision: 226433
> URL: http://svn.freebsd.org/changeset/base/226433
>
> Log:
> Update the comment and description of tcp_sendspace and tcp_recvspace
> to better reflect thei
On Fri, Oct 28, 2011 at 05:40:35PM -0700, Doug Barton wrote:
> > ==
> > --- head/usr.bin/sed/sed.1 Fri Oct 28 20:00:30 2011(r226888)
> > +++ head/usr.bin/sed/sed.1 Fri Oct 28 20:28:13 2011(r226889)
> > @@
On Thu, Nov 10, 2011 at 01:44:06AM +, Kevin Lo wrote:
> - == static void p_ere(struct parse *p, int stop);
> + == static void p_ere(struct parse *p, wint_t stop);
> */
> static void
> p_ere(struct parse *p,
> - int stop) /* character this ERE should end at */
> + wint_
On Tue, Nov 15, 2011 at 05:49:24AM +, David Schultz wrote:
> Author: das
> Date: Tue Nov 15 05:49:24 2011
> New Revision: 227520
> URL: http://svn.freebsd.org/changeset/base/227520
>
> Log:
> Further reduce diffs with OpenBSD's arc4random. The main functional
> change here is to ensure th
On Thu, Jun 23, 2011 at 03:10:44PM +, Alexander Motin wrote:
> Author: mav
> Date: Thu Jun 23 15:10:44 2011
> New Revision: 223475
> URL: http://svn.freebsd.org/changeset/base/223475
>
> Log:
> Fix ATAPI breakage introduced by r223443. It made SCSI commands to ATAPI
> device to never compl
On Thu, Jun 23, 2011 at 08:00:10PM +0400, Andrey Chernov wrote:
> On Thu, Jun 23, 2011 at 03:10:44PM +, Alexander Motin wrote:
> > Author: mav
> > Date: Thu Jun 23 15:10:44 2011
> > New Revision: 223475
> > URL: http://svn.freebsd.org/changeset/base/223475
&g
: Attempt to query device size failed: NOT READY, Medium not present - tray
closed
On Thu, Jun 23, 2011 at 08:24:58PM +0400, Andrey Chernov wrote:
> On Thu, Jun 23, 2011 at 08:00:10PM +0400, Andrey Chernov wrote:
> > On Thu, Jun 23, 2011 at 03:10:44PM +, Alexander Motin wrote:
> >
On Sun, Jun 26, 2011 at 01:14:54AM +, Justin T. Gibbs wrote:
> Author: gibbs
> Date: Sun Jun 26 01:14:54 2011
> New Revision: 223556
> URL: http://svn.freebsd.org/changeset/base/223556
>
> Log:
> cam/cam_xpt.c:
> In camisr_runqueue(), we need to run the sims queue regardless of
>
On Sun, Jul 17, 2011 at 04:10:00AM +, Doug Barton wrote:
> Author: dougb
> Date: Sun Jul 17 04:10:00 2011
> New Revision: 224122
> URL: http://svn.freebsd.org/changeset/base/224122
>
> Log:
> Fix the location of the default pid file in named.8
There something wrong now with another default
On Sun, Jul 17, 2011 at 03:42:57AM -0700, Doug Barton wrote:
> On 07/17/2011 02:49, Andrey Chernov wrote:
>
> > There something wrong now with another default or missing file.
> > I got
> > named[3322]: managed-keys-zone ./IN: loading from master file
> > mana
On Sun, Apr 24, 2011 at 09:23:08AM +, Alexander Motin wrote:
> ATA device names in /etc/fstab or other places, make sure to update
> them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY,
> - where 'Y's are the sequential numbers for each type in order of
> -
On 21.03.2014 19:15, Gleb Smirnoff wrote:
> - Remove rt_metrics_lite and simply put its members into rtentry.
> - Use counter(9) for rt_pksent (former rt_rmx.rmx_pksent). This
> removes another cache trashing ++ from packet forwarding path.
> - Create zini/fini methods for the rte
On 22.03.2014 0:07, Andrey Chernov wrote:
> /usr/src/usr.bin/netstat/route.c:333:7: error: format specifies type
> 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long
> long') [-Werror,-Wformat]
>
On 31.03.2014 3:43, Warner Losh wrote:
> Author: imp
> Date: Sun Mar 30 23:43:30 2014
> New Revision: 263953
> URL: http://svnweb.freebsd.org/changeset/base/263953
Somewhere after your mk changes (I think, previous files) typing 'make'
in /usr/src/lib produce that:
make: "/usr/share/mk/bsd.subdir
On 05.05.2014 20:41, Pedro F. Giffuni wrote:
> Log:
> regex: Use calloc instead of malloc.
>
> Mostly to reduce differences with OpenBSD.
Please don't commit OpenBSD errors. Now you mix calloc() with the
realloc() for the same variable later which makes calloc() zeroing
pointless and waste
On 05.05.2014 22:28, David Chisnall wrote:
> On 5 May 2014, at 18:42, Andrey Chernov wrote:
>
>> Please don't commit OpenBSD errors. Now you mix calloc() with the
>> realloc() for the same variable later which makes calloc() zeroing
>> pointless and waste of CP
On 06.05.2014 1:43, David Chisnall wrote:
> While reallocf() is nice, it doesn't address the problem of overflow. It
> takes a single size, forcing the caller to do the number-of-elements *
> element-size multiplication, which is the problematic one. If an attacker
> can control the number of
On 06.05.2014 1:52, David Chisnall wrote:
> This is not relying on undocumented intrinsic knowledge, this is relying on
> the standard library doing what is required of it. There is a reason why
> secure coding standards have, for over a decade, said to prefer calloc() over
> malloc() unless pr
On 06.05.2014 2:12, David Chisnall wrote:
> On 5 May 2014, at 22:51, Andrey Chernov wrote:
>
>> For standard malloc/realloc interface it is up to the caller to check
>> n*size not overflows. You must trust caller already does such check.
>
> Do a search of the CVE data
On 06.05.2014 2:52, Andrey Chernov wrote:
> As I mention initially, literal enough checks is what we need to make
> logic clear. In the case we discuss realloc() can be changed by
> reallocf() which does n*size and NULL checks and literal "if" should be
> added before mall
On 06.05.2014 2:59, Warner Losh wrote:
> Stupid is as stupid does. malloc and realloc both have this same issue. While
> an interesting theoretical attack, the size doesn’t necessarily come from
> multiplication. Careful coding is still required, not matter what spin you
> put on this. reallocf(
On 18.06.2013 4:36, Scott Long wrote:
> Author: scottl
> Date: Tue Jun 18 00:36:53 2013
> New Revision: 251874
> URL: http://svnweb.freebsd.org/changeset/base/251874
===> amd (all)
cc -O2 -pipe -march=prescott -fno-strict-aliasing -Werror -D_KERNEL
-DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HE
On 18.06.2013 7:34, Scott Long wrote:
> Author: scottl
> Date: Tue Jun 18 03:34:08 2013
> New Revision: 251888
> URL: http://svnweb.freebsd.org/changeset/base/251888
>
> Log:
> Catch up to the changes from r251874. This isn't an MFC because the
> amd(4) driver no longer exists in FreeBSD 10.
On 02.07.2013 11:39, Bruce Evans wrote:
> The bugs are a little different than I said above. There is no overflow
> problem and no problem with invalid values being produces, since the
> algorithm from ACM is careful to do everything with 32 bit signed
> integers without causing overflow. The alg
On 02.07.2013 20:33, Bruce Evans wrote:
> I checked the values returned by rand(). The ACM part works as
> intended, so it never returns RAND_MAX. It also never returns 0. So
> the distribution of values in the documented range [0, RAND_MAX] is
> very non-uniform. It is uniform in [1, RAND_MAX
On 04.07.2013 6:47, Bruce Evans wrote:
> Er, I think it is too dangerous to change either RAND_MAX or the offset
> without more preparation:
> - increasing the range returned (and increasing RAND_MAX to match) would
> obviously be binary-incompatible. Old binaries may have the old RAND_MAX
> b
On 04.07.2013 11:01, Bruce Evans wrote:
>> We already pass that moment in the past, changing old&bad formula with
>> new one which cause the same effect: non-repeating sequence in the very
>> global scope. We already agree that repeating depends on something like
>> OS release numbers. I can't find
On 04.07.2013 16:30, Dmitry Morozovsky wrote:
> On Thu, 4 Jul 2013, Andrey Chernov wrote:
>
>>>> We already pass that moment in the past, changing old&bad formula with
>>>> new one which cause the same effect: non-repeating sequence in the very
>>>>
On 16.07.2013 11:26, Andriy Gapon wrote:
> Modified: head/lib/libc/stdlib/getenv.c
> ==
> --- head/lib/libc/stdlib/getenv.c Tue Jul 16 06:50:22 2013
> (r253379)
> +++ head/lib/libc/stdlib/getenv.c Tue Jul 16
On 17.07.2013 8:10, Andrey Chernov wrote:
> On 16.07.2013 11:26, Andriy Gapon wrote:
>> Modified: head/lib/libc/stdlib/getenv.c
>> ==
>> --- head/lib/libc/stdlib/getenv.cTue Jul 16 06:50:22 201
On 17.07.2013 8:48, Andrey Chernov wrote:
> On 17.07.2013 8:10, Andrey Chernov wrote:
>> On 16.07.2013 11:26, Andriy Gapon wrote:
>>> Modified: head/lib/libc/stdlib/getenv.c
>>> ==
>>&g
On 17.07.2013 12:35, Andriy Gapon wrote:
> - env = stpcpy(envVars[envNdx].name, name);
> + env = stpncpy(envVars[envNdx].name, name, nameLen);
> if ((envVars[envNdx].name)[nameLen] != '=')
> env = stpcpy(env, "=");
>> Microoptimized:
>>
>>
Forget to mention, it was MFC r252608,252648,252668,252698
On 24.07.2013 14:12, Andrey A. Chernov wrote:
> Author: ache
> Date: Wed Jul 24 10:12:50 2013
> New Revision: 253607
> URL: http://svnweb.freebsd.org/changeset/base/253607
>
> Log:
> 1) POSIX requires rand(3) return values to be in the
On 24.07.2013 12:56, Andriy Gapon wrote:
> Author: avg
> Date: Wed Jul 24 08:56:59 2013
> New Revision: 253600
> URL: http://svnweb.freebsd.org/changeset/base/253600
>
> Log:
> MFC r253380,253413: name passed into __setenv is not necessarily
> NUL-terminated
>
Why MFC to stable/9 is pending?
On 03.04.2013 11:04, Bruce Evans wrote:
>> +mib[0] = CTL_KERN;
>> +mib[1] = KERN_ARND;
>> +sysctl(mib, 2, (void *)&next, &len, NULL, 0);
>> }
>
> The sysctl() is certain to fail on old kernels (like open of /dev/random
> on even older kernels), but there is no longer any error checking
On 04.04.2013 9:24, Xin Li wrote:
> True, but keep mind that neither random(3) nor rand(3) is intended to
> satisfy cryptographically secure needs, and I don't see a reason why
> kernel arc4 can not be improved.
Danger level here is not to get something cryptographically less secure,
but even much
The bug eye-catched:
On 23.04.2013 5:09, Kirk McKusick wrote:
> + case 'k':
> + found_arg = 1;
> + name = "space to hold for metadata blocks";
> + kvalue = atoi(optarg);
> + if (mvalue < 0)
On 25.04.2013 12:26, Ronald Klop wrote:
> Hi,
>
> Maybe I need more coffee, but I don't see a difference between the if
> and the else statements in the hptmv file.
shutdown_kproc vs. kproc_shutdown
>
> Regards,
> Ronald.
>
> On Wed, 24 Apr 2013 21:00:45 +0200, Alexander Motin
> wrote:
>
>>
On 12.03.2014 18:29, Gleb Smirnoff wrote:
> --- head/sys/netinet/ip_input.c Wed Mar 12 12:27:13 2014
> (r263090)
> +++ head/sys/netinet/ip_input.c Wed Mar 12 14:29:08 2014
> (r263091)
> @@ -794,6 +795,8 @@ SYSCTL_PROC(_net_inet_ip, OID_AUTO, maxf
> NULL, 0, sysctl_m
On 30.07.2013 0:58, David E. O'Brien wrote:
> Author: obrien
> Date: Mon Jul 29 20:58:09 2013
> New Revision: 253786
> URL: http://svnweb.freebsd.org/changeset/base/253786
>
> Log:
> Decouple yarrow from random(4) device.
>
> * Make Yarrow an optional kernel component -- enabled by "YARROW_
On 30.07.2013 22:50, David O'Brien wrote:
> Hi DES,
> Where was this policy published or communicated?
> There is no MAINTAINER line in sys/dev/random/, nor an entry in
> /usr/src/MAINTAINERS. It is hard to follow some policy that cannot
> be found.
~5 years ago I was forced to stop commits due t
On 31.07.2013 4:07, David O'Brien wrote:
> I believe you're talking about this code in
> sys/libkern/arc4random.c:arc4rand()
>
> if (atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_HAVE,
> ARC4_ENTR_SEED) || reseed ||
> (arc4_numruns > ARC4_RESEED_BYTES) ||
>
On 31.07.2013 4:15, David O'Brien wrote:
> On Tue, Jul 30, 2013 at 05:07:46PM -0700, David O'Brien (@FreeBSD) wrote:
>> I believe you're talking about this code in
>> sys/libkern/arc4random.c:arc4rand()
>>
>> if (atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_HAVE,
>> ARC4_ENTR_
On 31.07.2013 21:46, David O'Brien wrote:
> I realize the motivation for your r249631 change.
>
> But as it relates to the change I committed, there is no change in
> behavior in this. If one is using a hardware RNG, yarrow is not
> initialized and so the ARC4_ENTR_NONE -> ARC4_ENTR_HAVE transiti
On 05.08.2013 5:57, Alexey Dokuchaev wrote:
> Nice, could you please MFC it to stable/8 as well?
usr.bin/grep does not exist in stable/8
--
http://ache.vniz.net/
bitcoin:1G6ugdNY6e5jx1GVnAU2ntj2NEfmjKG85r
___
svn-src-all@freebsd.org mailing list
http:
On 21.08.2013 20:46, Sergey Kandaurov wrote:
> number = strtoumax(buf, &endptr, 0);
>
> + if (number == UINTMAX_MAX && errno == ERANGE) {
> + return (-1);
> + }
You need to reset errno before strtoumax() call (errno = 0), because any
of previous functions may left it as
On 22.08.2013 1:37, Jilles Tjoelker wrote:
>> if (number == UINTMAX_MAX && errno == ERANGE) {
>> return (-1);
>> }
>>
>> + if (errno == 0)
>> + errno = saved_errno;
>> +
> This looks good to me.
>
Just being nitpicking) number == UINTMAX_MAX c
On 22.08.2013 14:01, Andrey Chernov wrote:
> On 22.08.2013 1:37, Jilles Tjoelker wrote:
>>> if (number == UINTMAX_MAX && errno == ERANGE) {
>>> return (-1);
>>> }
>>>
>>> + if (errno == 0)
>>>
On 03.09.2013 17:31, Ed Maste wrote:
> Author: emaste
> Date: Tue Sep 3 13:31:43 2013
> New Revision: 255175
> URL: http://svnweb.freebsd.org/changeset/base/255175
>
> Log:
> Don't install private libexecinfo headers
Perhaps it should be added to obsolete files cleanup...
--
http://ache.vniz
On 01.05.2013 2:13, Brooks Davis wrote:
> + Due to the use of the new -l option to install(1) during build
> + and install, you must take care not to directly set the INSTALL
> + make variable in your /etc/make.conf, /etc/src.conf, or on the
> + command line. If you with to use the
On 01.05.2013 2:13, Brooks Davis wrote:
> +#
> +# install(1) parameters.
> +#
> +HRDLINK?=-l h
> +SYMLINK?=-l s
It is error, there must be no space or "-" sign.
--
bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N
___
svn-src-all@freebsd.org mailing l
On 02.05.2013 9:09, Andrey Chernov wrote:
> On 01.05.2013 2:13, Brooks Davis wrote:
>> +#
>> +# install(1) parameters.
>> +#
>> +HRDLINK?= -l h
>> +SYMLINK?= -l s
>
> It is error, there must be no space or "-" sign.
Sorry my mistake. All right
I don't think this change is optimal (cause slowdown) since you add
unneeded strlen() in the loop for known-sized elements plus one strlen()
for tested property, and wctype_l() itself can be called very often, so
we definitely don't need slowdown here.
Since most of elements have equal sizes, your
On 04.05.2013 0:48, Sergey Kandaurov wrote:
> On 3 May 2013 23:55, Jilles Tjoelker wrote:
>> Some sort of perfect hashing can also be an option, although it makes it
>> harder to add new properties or adds a build dependency on gperf(1) that
>> we would like to get rid of.
> I hacked a bit on wcty
On 04.05.2013 16:03, Sergey Kandaurov wrote:
>> BTW, I don't run tests and look in asm code for sure, but it seems
>> property[0] == p[0] is unneeded because almost every compiler tries to
>> inline strcmp().
>
> Doesn't seem so (in-lining), see below.
Yes, system's GNU cc don't inline strcmp() b
On 04.05.2013 21:21, Sergey Kandaurov wrote:
> Log:
> Document that the return type is different from 1003.1-2008.
>
It is better to fix this function return type to match POSIX standard
rather than to document its non-standard behavior. We try to follow
POSIX when possible and this is the ca
On 06.05.2013 1:03, David Chisnall wrote:
> On 5 May 2013, at 19:31, Andrey Chernov wrote:
>
>> It is better to fix this function return type to match POSIX standard
>> rather than to document its non-standard behavior. We try to follow
>> POSIX when possible and this is
On 12.05.2013 20:50, Alan Cox wrote:
GNU cc errors related to part of diff below:
cc1: warnings being treated as errors
../../../vm/vm_page.c: In function 'vm_page_alloc':
../../../vm/vm_page.c:1209: warning: 'mpred' may be used uninitialized
in this function
*** [vm_page.o] Error code 1
Formally
On 22.05.2013 2:20, Ed Schouten wrote:
> 2013/5/22 Jilles Tjoelker :
>> Our wchar_t is only ISO 10646 for UTF-8 and possibly US-ASCII and
>> ISO8859-1 (subset) locales.
>
> Oh, the horror! I thought on FreeBSD, we used the LC_CTYPE files to do
> a mapping to ISO 10646. Unfortunately, it seems to b
On Sun, Mar 04, 2012 at 09:31:13PM +, Robert Millan wrote:
> Author: rmh
> Date: Sun Mar 4 21:31:13 2012
> New Revision: 232521
> URL: http://svn.freebsd.org/changeset/base/232521
>
> Log:
> Exclude USB drivers (except umass and ukbd) from main kernel image on i386
> and amd64.
IMHO, gen
On Sat, Dec 24, 2011 at 02:26:20AM -0800, Xin LI wrote:
> chroot(2) can create legitimate and secure environment where dlopen(2)
> is safe and necessary.
It seems it is internal contradiction in your argumentation:
1) You state that chroot(2) can create legitimate environment.
2) For ftpd's you di
On Sun, Jan 15, 2012 at 02:44:35AM -0800, Xin LI wrote:
> Why you need anything if the program needs to run something inside the
> chroot, which means one already have set up a full chroot environment?
1) ftpds usually not allows to run any program by default. Max default set
usualy is: ls, tar,
On Mon, Jan 16, 2012 at 08:18:10PM +, David Schultz wrote:
> Author: das
> Date: Mon Jan 16 20:18:10 2012
> New Revision: 230230
> URL: http://svn.freebsd.org/changeset/base/230230
>
> Log:
> Generate a warning if the kernel's arc4random() is seeded with bogus
> entropy.
While you are here
On Wed, Jan 18, 2012 at 12:54:40PM -0500, David Schultz wrote:
> It appears to reseed arc4random's state exactly once, at whatever
> unpredictable time devrandom decides to reseed itself. Are you
As fast as possible, immediatelly when we have enough good entropy.
> trying to fix the problems tha
On Thu, Jan 19, 2012 at 07:52:30PM +, Mark Murray wrote:
> Andrey Chernov writes:
> > On Mon, Jan 16, 2012 at 08:18:10PM +, David Schultz wrote:
> > > Author: das
> > > Date: Mon Jan 16 20:18:10 2012
> > > New Revision: 230230
> > > URL:
On Fri, Jan 20, 2012 at 03:12:53PM +, Mark Murray wrote:
> Andrey Chernov writes:
> > > Look at the function random_yarrow_unblock(). Thats where yopu want to
> > > be doing this. This function is where the random device is unblocked
> > > once safely seeded.
>
On Sun, Jan 22, 2012 at 04:59:55PM +, Mark Murray wrote:
> Andrey Chernov writes:
> > > The usual way round this is with a flag. Set a static, volatile
> > > flag, defaulting "off", and set it to "on" when the seeding has
> > > happened. Then
On Sun, Jan 22, 2012 at 09:43:02PM +, Mark Murray wrote:
> > Thanx for review! I'll send final version to this thread a bit
> > later when I'll find more free time.
Final, unless something else noticed.
--- sys/libkern.h.bak 2012-01-16 07:15:12.0 +0400
+++ sys/libkern.h 2012-
On Wed, Jan 25, 2012 at 07:16:41PM +, Mark Murray wrote:
> I thought you were going to do this as a function? It would be
> slightly neater to do it that way.
>
> Looks good! Are you sure this needs no locking or volatile
> variables?
Now with function, volatile, atomic and even enum:
--- sy
On Thu, Jan 26, 2012 at 07:03:05AM +0400, Andrey Chernov wrote:
> On Wed, Jan 25, 2012 at 07:16:41PM +, Mark Murray wrote:
> > I thought you were going to do this as a function? It would be
> > slightly neater to do it that way.
> >
> > Looks good! Are you su
On Thu, Jan 26, 2012 at 08:39:07AM -0500, John Baldwin wrote:
> What is the purpose of the atomics? Doing atomic_load/atomic_store
> is just as racy as if you had not used atomics at all.
Thanx for a hint.
Protecting comparison itself isn't essential as protecting variable
consitency because r
> On Thu, Jan 26, 2012 at 08:39:07AM -0500, John Baldwin wrote:
> > atomic_cmpset_int(&iniseed_state, ARC4_ENTER_NONE,
> > ARC4_ENTER_HAVE);
> > break;
Updated version (I hope, final):
--- sys/libkern.h.old 2012-01-16 07:15:12.0 +0400
+++ sys/libkern.h 201
On Thu, Jan 26, 2012 at 11:32:38AM -0500, John Baldwin wrote:
> On Thursday, January 26, 2012 10:56:27 am Andrey Chernov wrote:
> > > On Thu, Jan 26, 2012 at 08:39:07AM -0500, John Baldwin wrote:
> > > > atomic_cmpset_int(&iniseed_state, ARC4_EN
> On Thu, Jan 26, 2012 at 11:32:38AM -0500, John Baldwin wrote:
> > Atomics don't operate on enums. You'll need to make it an int and just use
> > #define's for the 3 states.
--- sys/libkern.h.old 2012-01-16 07:15:12.0 +0400
+++ sys/libkern.h 2012-01-26 21:40:21.0 +0400
@
On Thu, Jan 26, 2012 at 12:52:43PM -0500, David Schultz wrote:
> Why complicate things with atomics at all? A race might result in
> arc4random(9) being seeded multiple times, but that's harmless.
Multiply seeding in line is harmless, just waste of time and resources.
Other case is one missing se
On Fri, Jan 27, 2012 at 08:34:35PM +1100, Bruce Evans wrote:
> On Thu, 26 Jan 2012, Andrey Chernov wrote:
>
> >> On Thu, Jan 26, 2012 at 11:32:38AM -0500, John Baldwin wrote:
> >>> Atomics don't operate on enums. You'll need to make it an int and just
>
New verson addressed bde's style things:
--- sys/libkern.h.old 2012-01-16 07:15:12.0 +0400
+++ sys/libkern.h 2012-01-28 08:49:19.0 +0400
@@ -70,6 +70,11 @@ static __inline int abs(int a) { return
static __inline long labs(long a) { return (a < 0 ? -a : a); }
static __inl
On Sat, Jan 28, 2012 at 06:47:50PM +1100, Bruce Evans wrote:
> > --- sys/libkern.h.old 2012-01-16 07:15:12.0 +0400
> > +++ sys/libkern.h 2012-01-28 08:49:19.0 +0400
> > @@ -70,6 +70,11 @@ static __inline int abs(int a) { return
> > static __inline long labs(long a) { return
On Thu, Jan 26, 2012 at 10:13:41PM +0400, Andrey Chernov wrote:
> On Thu, Jan 26, 2012 at 12:52:43PM -0500, David Schultz wrote:
> > Why complicate things with atomics at all? A race might result in
> > arc4random(9) being seeded multiple times, but that's harmless.
>
>
On Mon, Jan 30, 2012 at 11:30:15AM +, Mark Murray wrote:
> > Well, I almost forget about my special case: I have personal prohibition
> > from @secteam (5 years old already) to commit anything to all RNG areas.
> >
> > So, the question is: could anyone of you commit some version from this
>
On Tue, Feb 07, 2012 at 05:46:02PM +, Martin Matuska wrote:
> Author: mm
> Date: Tue Feb 7 17:46:02 2012
> New Revision: 231138
> URL: http://svn.freebsd.org/changeset/base/231138
>
> Log:
> MFC r230495:
> Try resolving jail path with realpath(3).
Please note that our realpath(3) is far
On Thu, Feb 09, 2012 at 08:51:03PM +, Eitan Adler wrote:
> /* Prefix should add an @cwd to the packing list */
> -if (Prefix)
> - add_plist_top(&plist, PLIST_CWD, Prefix);
> +if (Prefix) {
> +char resolved_prefix[PATH_MAX];
> +if (realpath(Prefix, resolved_prefi
On 24.11.2012 8:15, Andrew Turner wrote:
> The is_delim function works on wchar_t characters not ints, update the
> function to take a wchar_t as it's argument.
> static int
> -is_delim(int ch)
> +is_delim(wchar_t ch)
> {
> if (wflag) {
> if (ch == ' ' || ch == '\t')
>
I
On 24.11.2012 18:12, Dimitry Andric wrote:
>>> -is_delim(int ch)
>>> +is_delim(wchar_t ch)
>>> {
>>> if (wflag) {
>>> if (ch == ' ' || ch == '\t')
>>>
>>
>> I can't look at the whole code at this moment, but taking standalone
>> this is incorrect comparison for wchar_t. Should be
1 - 100 of 336 matches
Mail list logo
