> In message <[EMAIL PROTECTED]> "David O'Brien" writes:
> : On Tue, Nov 23, 1999 at 09:15:35PM -0800, Kris Kennaway wrote:
> : > - (void)fgets(message, sizeof(message), stdin);
> : > + (void)fgets(message, MAXMSG, stdin);
> :
> : There is nothing wrong with the original line here
In message <[EMAIL PROTECTED]> Forrest Aldrich writes:
: Why does ps not show the full path on 4.0 as in 3.3?
: (for non-root users)
Because you have caught things in the middle of a change. There will
be a sysctl that will control this behavior shortly.
Warner
To Unsubscribe: send mail to [E
Hmmm, but now that you have changed message to be a pointer, the
sizeof(message) at the end of the patch will return the size of
a pointer which is 4 and probably not what you want. :-)
I think we should be carefull when we make our security fixes so
that we don't introduce new bugs, which was al
In message <[EMAIL PROTECTED]> Kris Kennaway
writes:
: I'll commit this tomorrow (just wanted to get in a 'first post!' :-)..
Please don't. Please use a proper fix instead.
: /* Have now read in the data. Next get the message to be printed. */
: if (*argv) {
: - strcpy(
In message <[EMAIL PROTECTED]> Brian
Fundakowski Feldman writes:
: I'd prefer something like this that I've attached. The move over the
: years has been away from artificial limits...
: @@ -1058,14 +1058,24 @@
:
: /* Have now read in the data. Next get the message to be printed. */
:
In message <[EMAIL PROTECTED]> "David O'Brien" writes:
: On Tue, Nov 23, 1999 at 09:15:35PM -0800, Kris Kennaway wrote:
: > - (void)fgets(message, sizeof(message), stdin);
: > + (void)fgets(message, MAXMSG, stdin);
:
: There is nothing wrong with the original line here. Pleas
In message <[EMAIL PROTECTED]> Brian
Fundakowski Feldman writes:
: Despite the fact that the buffer name[] was made to be exactly the
: largest size, where sprintf() _would_be_safe_, some people insist
: on using snprintf() "for stability". Don't get caught doing this.
: If you find a strcat() (
In message <[EMAIL PROTECTED]> Peter Jeremy writes:
: I wasn't implying that. In fact, I believe the semantics of strncat()
: put it into the `hard to use correctly' category (or maybe `very likely
: to be misused').
I'd put strncat in the definitely unsafe category based on the number
of bugs t
In message <[EMAIL PROTECTED]> Peter Jeremy writes:
: I suspect that a 'cvs diff' of the OpenBSD code tree is the best
: starting point.
As a veteran of that war, I think you underestimate that task be about
a few orders of magnitude. A better starting point I've found to be
the ChangeLog files
In message <[EMAIL PROTECTED]> Kris Kennaway
writes:
: Yep, this is part of the "education" component: "this is what an unsafe
: function call looks like, and this is how to fix it". There's bound to be
: enough useful documentation out there which we can collect and point to.
__warn_references(
In message <[EMAIL PROTECTED]> Kris Kennaway
writes:
:
: Maybe what we actually want is a better RCS system for FreeBSD.
:
http://www.perforce.com/
:-)
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In message <[EMAIL PROTECTED]> Mark Murray writes:
: o unsafe use of the str*(3) functions; strcat/strcpy/sprintf &c.
Keep a keen eye out for unsafe uses of strncpy and strncat and know
the man page by heart before thinking you are correct :-)
: o &c. please contribute here
I had a long lis
:> > and people who need to hide it can set it to "close" to do so.
:>
:> Please. Thank you.
:>
:> Not everyone wears the sysadmin hat with the face shield and gas mask,
:> as much as it may currently be in style. If it can work both ways,
:> even better.
:
:Definately! This is NOT AN ACCEPT
Christopher Masto wrote:
> On Wed, Nov 24, 1999 at 12:54:15AM +0100, Poul-Henning Kamp wrote:
> > I'm personally leaning towards the opinion that the argv is public
> > property and should be visible, but then again, I can see the point
> > in hiding it in some circumstances.
> >
> > I'll stick a
Dan Nelson wrote:
> In the last episode (Nov 23), Lyndon Nerenberg said:
> > After you verify that this change isn't going to break things that
> > assume they can see the *argv list via ps(1). I.e. lightning bolts
> > that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant
> > style, b
> > > - (void)fgets(message, sizeof(message), stdin);
> > > + (void)fgets(message, MAXMSG, stdin);
> >
> > There is nothing wrong with the original line here. Please don't change
> > things that are fine just to change them. We don't want to ofuscate
>
> Obviously not, but I d
> Hey guys, can we move this discussion over to security? I don't
> think it's -current fodder. :)
Actually, I'd like to start a whole new list - freebsd-audit - if
that is OK with you. I have a conference to attend, but if this is OK
I'll set it up in about 9 hours.
M
--
Mark Murray
Join the a
On Tue, 23 Nov 1999, David O'Brien wrote:
> On Tue, Nov 23, 1999 at 09:15:35PM -0800, Kris Kennaway wrote:
> > - (void)fgets(message, sizeof(message), stdin);
> > + (void)fgets(message, MAXMSG, stdin);
>
> There is nothing wrong with the original line here. Please don't chan
Hey guys, can we move this discussion over to security? I don't
think it's -current fodder. :)
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Tue, Nov 23, 1999 at 09:15:35PM -0800, Kris Kennaway wrote:
> - (void)fgets(message, sizeof(message), stdin);
> + (void)fgets(message, MAXMSG, stdin);
There is nothing wrong with the original line here. Please don't change
things that are fine just to change them. We
On Wed, 24 Nov 1999, Peter Jeremy wrote:
> On 1999-Nov-24 15:33:14 +1100, Brian Fundakowski Feldman wrote:
> >I'd like to note something. Strcat isn't necessarily unsafe, and strncat()
> >isn't necessarily safe.
>
> I wasn't implying that. In fact, I believe the semantics of strncat()
> put it
On Tue, Nov 23, 1999 at 11:49:28PM -0600, Juan Amado Becerril Castillo wrote:
> How I can install Apache_1.3.9 with the option
> EXTRA_CFLAGS=-DBIG_SECURITY_HOLE from ports ?
By asking this question of [EMAIL PROTECTED] rather than here.
--
-- David([EMAIL PROTECTED])
To Unsubscribe: s
> I'm not sure how to fix this problem. Unlike our other build tools,
> perl is not designed to be able to be cross-built: It builds bits
> of itself and assumes they can be safely executed to build other bits.
Perl is hugely fragile; cross-building it is a big PITA. If you
have any smart ideas
> In the last episode (Nov 23), Lyndon Nerenberg said:
> > After you verify that this change isn't going to break things that
> > assume they can see the *argv list via ps(1). I.e. lightning bolts
> > that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant
> > style, but sometimes is th
On Wed, 24 Nov 1999, Peter Jeremy wrote:
> A 'grep | wc' equivalent over the source tree gives:
>
> gets110
> strcat 2860
> strcpy 4717
> strncat 167
> strncpy1514
> sprintf6839
> vsprintf133
>
...
> A string search for (roughly) "scanf.*%s" also picks up 74 case
I'd prefer something like this that I've attached. The move over the
years has been away from artificial limits...
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
Index: banner.c
How I can install Apache_1.3.9 with the option
EXTRA_CFLAGS=-DBIG_SECURITY_HOLE from ports ?
Thanks.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
>
> I assume make(1) has been built, because that's the first constructive
> thing that happens. Can you check that it has been installed?
Yes it has and it looks ok. It almost looks like the path is screwed up.
In the meantime I played a bit around and this hack makes it work. Maybe
that can he
On 1999-Nov-24 15:33:14 +1100, Brian Fundakowski Feldman wrote:
>I'd like to note something. Strcat isn't necessarily unsafe, and strncat()
>isn't necessarily safe.
I wasn't implying that. In fact, I believe the semantics of strncat()
put it into the `hard to use correctly' category (or maybe `
In the spirit of the newly-formed FreeBSD Auditing Project, I present:
% banner `perl -e 'print "a"x2000'`
Segmentation fault(core dumped)
-
The problem is a trivial one. From /usr/src/usr.bin/banner/banner.c:
/*
* banner - prints large signs
* banner [-w#] [-d] [-t] message ...
*/
#de
On Tue, 23 Nov 1999, Kelly Yancey wrote:
> > I think it would be useful to identify "unsafe" functions, so that
> > anyone can participate in the "eyeball" portion of the game. This means
> > that we need eyeballed, identified as a (potential) problem and fixed,
> > as well as some other possiblit
On Tue, 23 Nov 1999, David O'Brien wrote:
> > Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current
> > buildworld running on an older -current system now progresses much
> > further - in fact it now completes :-).
>
> Actually, I've been seeing just the opposite.
> Before you could
On Wed, Nov 24, 1999 at 12:54:15AM +0100, Poul-Henning Kamp wrote:
> I'm personally leaning towards the opinion that the argv is public
> property and should be visible, but then again, I can see the point
> in hiding it in some circumstances.
>
> I'll stick a sysctl in there which defaults to th
> Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current
> buildworld running on an older -current system now progresses much
> further - in fact it now completes :-).
Actually, I've been seeing just the opposite.
Before you could build a -CURRENT kernel and then the world. Now those
> Anyone have any ideas whats going on here?
Yep. ;-)
> yacc: e - line 30 of "c-parse.y", syntax error
> %expect 51
> ^
> *** Error code 1
The problem is rev 1.92 of src/Makefile.inc1. With that change, the
tools needed to build GCC aren't made first. I added a few Bison-like
features to By
I seem to recall that conversation here in the mailing list.
How about a system configuration variable that determines what info
like ps (and friends) can access?
Personally, I would just prefer to leave it be. There are too many other
potential problems with scripts and such that depend upon
> I don't see any reason, for example, why anyone should still be using
> gets() and our implementation even gets whiney about it if you do.
That one is definitely up for a global search and replace as its only use
is to read external data.
--
-- David([EMAIL PROTECTED])
To Unsubscribe:
> Lint no longer works in -current as cpp seems to have lost the -undef
> option.
Yes, looking into `cpp' is on my list of things to do.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Peter Jeremy writes:
| Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current
| buildworld running on an older -current system now progresses much
| further - in fact it now completes :-).
|
| There are, however still a few problems - as far as I can tell, these
| are all related to t
I'm trying to build a CURRENT system from the 4.0 CURRENT snapshot cdroms
on 7-5-1999. I did a cvsup to cvsup4.freebsd.org, and attempted to build
world. It keeps on blowing up as illustrated below. I nuked the /usr/src
directory and then checked the source tree from our local mirror of the
mas
On 1999-Nov-24 12:02:59 +1100, Jordan K. Hubbard wrote:
> I don't see any reason, for
>example, why anyone should still be using gets()
To take gets() as an example, of the 110 occurrences that gid found in
-current, the following files contain actual calls to gets() (rather
than declarations, c
On Tue, 23 Nov 1999, Kris Kennaway wrote:
> On Tue, 23 Nov 1999, Kelly Yancey wrote:
> > Need volunteers, eh? I can be suckered in to helping in regards to
> > building the web-based database for keeping track of the effor's progress.
> > I may be no security expert, but I can build database-dri
> This means nothing out of context. I hope we don't go on a witch hunt.
No, but there is some merit to simply replacing these so that they
don't show up on our radar later. I don't see any reason, for
example, why anyone should still be using gets() and our
implementation even gets whiney abou
> I'm certainly willing to do what I can to help, although I have
> to admit that I may need a bit of help identifying what I can do. ;-)
That's Mark's job - he's the security leader. :)
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the b
> > 2) I propose that diff(1) FreeBSD with {Open|Net}BSD,
>
> This is not the easiest thing to do (I've tried). Rather one should look
> at what changes OpenBSD has done to a piece of code since they imported
> it from NetBSD and compare with FreeBSD code to see if the OpenBSD change
> is appli
Lint no longer works in -current as cpp seems to have lost the -undef
option. The option is still shown in the usage message and the man
page, but the code seems to have gone walk about!
David.
0:30:gonzo 92% uname -a
FreeBSD gonzo.home 4.0-CURRENT FreeBSD 4.0-CURRENT #17: Sat Nov 20 13:
Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current
buildworld running on an older -current system now progresses much
further - in fact it now completes :-).
There are, however still a few problems - as far as I can tell, these
are all related to the wrong version of perl being ca
In the last episode (Nov 23), Lyndon Nerenberg said:
> After you verify that this change isn't going to break things that
> assume they can see the *argv list via ps(1). I.e. lightning bolts
> that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant
> style, but sometimes is the only wor
>
> Jason, you are my savior. Go forth and do much to create Truly Kick Ass
> Threading. Give me my tools to smite these Linux database servers once
> and for all! :-)
Why do we need to smite the Linux database servers? With threads in their
current state they already outperform Linux's nativ
> "David" == David Malone <[EMAIL PROTECTED]> writes:
David> I guess it goes with the "stop ps showing the environment"
David> changes. If you remove one it makes sense to remove the
David> other.
After you verify that this change isn't going to break things that
assume they can
On Tue, 23 Nov 1999, Gerald Abshez wrote:
> Kris Kennaway wrote:
> >
> > Let me throw in some ideas..
> >
> > I think it would be very useful to have a database which can track
> > submitted open/netbsd CVS commits (with the code diff included),
> > preferably mapped to the relevant file in the f
On 1999-Nov-24 10:21:17 +1100, [EMAIL PROTECTED] wrote:
>a) This is what an unsafe function call looks like
Without checking a lot of the call context, it is very difficult
to categorically state that a particular function call is safe or
not. As an example, consider the following:
foo(const ch
On Tue, Nov 23, 1999 at 11:52:49PM +, Brian Somers wrote:
> Any comments Poul ? Is this anything to do with the recent command
> line buffering ?
I guess it goes with the "stop ps showing the environment" changes.
If you remove one it makes sense to remove the other.
David.
phk
In message <[EMAIL PROTECTED]>, Brian Somers writes:
>> In the last episode (Nov 23), Brian Somers said:
>> > $ ps jtva
>> > USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND
>> > root 222 1 222 9dac400 Is+ va0:00.01 (getty)
>> > $ sudo ps jtva
>> > USER PID PPID
According to Donn Miller:
> While we're on the subject of possibly borrowing code from NetBSD...
> NetBSD's wscons looks interesting. Any chance FreeBSD will adopt this, or
> will we stay with syscons?
What features does it have compared to syscons ?
--
Ollivier ROBERT -=- FreeBSD: The Power to
On Tue, Nov 23, 1999 at 05:11:37PM -0600, Dan Nelson wrote:
> Now that does look weird. After a bit more investigation, it looks
> like you can only get the full commandline of your own processes. Root
> can see all commandlines.
Yes, I can confirm it too on recently rebuilded -current.
Looks l
> In the last episode (Nov 23), Brian Somers said:
> > $ ps jtva
> > USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND
> > root 222 1 222 9dac400 Is+ va0:00.01 (getty)
> > $ sudo ps jtva
> > USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND
> > root 2
Hi,
Marcel Moolenaar <[EMAIL PROTECTED]>wrote:
> > A normal "make world" on current is ok, but a "make -j13 world" is broken.
> > I have looked at it a little bit, but I can't figure out what is going
> > wrong. It dies with:
I also found that "make -j world" is broken, with Makefile.inc1
rev 1.
On Tue, 23 Nov 1999, Peter Wemm wrote:
> Brian Fundakowski Feldman wrote:
> > Forget anything I said about KAME being the strong possibility :) As
> > soon as peter noted what commit it could have to do with, I figured
> > it out and fixed it; after testing, I committed it. Be happy :)
>
> You
> > Here is my 0.02:
> >
> > I think it would be useful to identify "unsafe" functions, so that
> > anyone can participate in the "eyeball" portion of the game. This means
> > that we need eyeballed, identified as a (potential) problem and fixed,
> > as well as some other possiblities. There is a
On Tue, 23 Nov 1999, David O'Brien wrote:
> On Tue, Nov 23, 1999 at 03:23:23PM -0500, Kelly Yancey wrote:
> > I may be no security expert,
>
> So??? You can read C code, right? What needs to happen is a leader to
> take charge and give people direction. If someone gave you a few
> sequences o
On 1999-Nov-24 09:26:26 +1100, David O'Brien wrote:
>> > A 'grep | wc' equivalent over the source tree gives:
>> >
>> > gets110
>> > strcat 2860
>> > strcpy 4717
>> > strncat 167
>> > strncpy1514
>> > sprintf6839
>> > vsprintf133
>>
>> *ouch* :-)
>
>This means not
On Wed, 24 Nov 1999, Bruce Evans wrote:
> Hmm. My netscape works, but I didn't use merge that commit. I had already
> inadvertly fixed the bug in another way while cleaning up.
>
> Indeed, the proplem is checking the new context before checking that the
> context is actually new.
>
> Here is
Hi,
"make -DWANT_AOUT world" on my current box fails because of the
recent changes to src/Makefile.inc1.
log starts here
--
>>> Building legacy libraries
--
c
In the last episode (Nov 23), Brian Somers said:
> $ ps jtva
> USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND
> root 222 1 222 9dac400 Is+ va0:00.01 (getty)
> $ sudo ps jtva
> USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND
> root 222 1 222
At 03:57 PM 11/23/99 , Vlad Skvortsov wrote:
> Sorry for probably a bit stupid question (I've been out of lists for
> a while). Are patches for named already in -current or -stable ?
>
No they have not to either. Use it out of the ports. Be sure to adjust
named-xfer "/usr/local/l
On Tue, 23 Nov 1999, David O'Brien wrote:
> > *ouch* :-)
>
> This means nothing out of context. I hope we don't go on a witch hunt.
Right, but they still need to be checked.
> Global search and replace of these can obfuscate code. Things must be
> looked for in context.
I hope no-one's sugg
At 12:05 PM -0800 1999/11/23, Jordan K. Hubbard wrote:
> Part of what will make this go a lot faster is people like yourself
> committing to sticking around and helping us find and fix any security
> problems we might have, so I certainly hope you can do this!
I'm certainly willing to do
> > A 'grep | wc' equivalent over the source tree gives:
> >
> > gets110
> > strcat 2860
> > strcpy 4717
> > strncat 167
> > strncpy1514
> > sprintf6839
> > vsprintf133
>
> *ouch* :-)
This means nothing out of context. I hope we don't go on a witch hunt.
> > A
> 2) I propose that diff(1) FreeBSD with {Open|Net}BSD,
This is not the easiest thing to do (I've tried). Rather one should look
at what changes OpenBSD has done to a piece of code since they imported
it from NetBSD and compare with FreeBSD code to see if the OpenBSD change
is applicable to us.
On Wed, 24 Nov 1999, Peter Jeremy wrote:
> >> o unsafe use of the str*(3) functions; strcat/strcpy/sprintf &c.
> >
> >I wonder how many instances of the potentially unsafe functions there are
> >in the source tree? :)
>
> A 'grep | wc' equivalent over the source tree gives:
>
> gets110
On Tue, 23 Nov 1999, Gerald Abshez wrote:
> Here is my 0.02:
>
> I think it would be useful to identify "unsafe" functions, so that
> anyone can participate in the "eyeball" portion of the game. This means
> that we need eyeballed, identified as a (potential) problem and fixed,
> as well as some
On Tue, 23 Nov 1999, David O'Brien wrote:
> A security review is never done. We need to be in a mode where every
> commit is suspect and people are compelled to review it. BDE's use of
> CTM to review changes is actually rather affective in this reguard.
A CVS tag would also accomplish this an
> So when Joe Blow clicks on (say) src->bin->cat he'll find that
> (say) markm eyballed the code and kris diffed it with OpenBSD
> and merged in fixes - "cat now considered safe".
Until the next commit to cat.
A security review is never done. We need to be in a mode where every
commit is suspe
Kris Kennaway wrote:
>
> Let me throw in some ideas..
>
> I think it would be very useful to have a database which can track
> submitted open/netbsd CVS commits (with the code diff included),
> preferably mapped to the relevant file in the freebsd tree if possible
> according to a path mapping ta
On Tue, Nov 23, 1999 at 03:23:23PM -0500, Kelly Yancey wrote:
> I may be no security expert,
So??? You can read C code, right? What needs to happen is a leader to
take charge and give people direction. If someone gave you a few
sequences of code to look for, you could find them right? If you
On Mon, 22 Nov 1999, Mark Murray wrote:
> > May this is not the best way for ftpd to use pam (many other lines for login,
> > may ftpd should be so). But I think ftpd should be listed in /etc/pam.conf.
> >
> > Any plan to fix it in /usr/src/etc/pam.conf ?
>
> On my list! :-)
>
rsh too, while
> Also useful would be a review status of the freebsd tree. So (approved)
> people can "sign off" on a particular file or directory as having been
> reviewed as of a certain date, and we can work in a coordinated fashion.
Well, IMHO what you guys most significantly need is a "tinderbox"
style pag
On 1999-Nov-24 06:35:16 +1100, Kris Kennaway wrote:
>> o unsafe use of the str*(3) functions; strcat/strcpy/sprintf &c.
>
>I wonder how many instances of the potentially unsafe functions there are
>in the source tree? :)
A 'grep | wc' equivalent over the source tree gives:
gets110
strcat
Dan Nelson wrote:
> In the last episode (Nov 23), Forrest Aldrich said:
>> Why does ps not show the full path on 4.0 as in 3.3? (for non-root
>> users)
>>
>> 4.0> ps -ax
>>
>>134 v2 Is+0:00.00 (getty)
>>135 v3 Is+0:00.00 (getty)
>>136 v4 Is+0:00.00 (getty)
>>
> In the last episode (Nov 23), Forrest Aldrich said:
> > Why does ps not show the full path on 4.0 as in 3.3? (for non-root
> > users)
> >
> > 4.0> ps -ax
> >
> >134 v2 Is+0:00.00 (getty)
> >135 v3 Is+0:00.00 (getty)
> >136 v4 Is+0:00.00 (getty)
> >137 v5
On Tue, 23 Nov 1999, Kelly Yancey wrote:
> Need volunteers, eh? I can be suckered in to helping in regards to
> building the web-based database for keeping track of the effor's progress.
> I may be no security expert, but I can build database-driven web sites (I
> should...it's my day job ;) ).
As Forrest Aldrich wrote ...
>
> Why does ps not show the full path on 4.0 as in 3.3?
> (for non-root users)
>
> ie:
>
> 4.0> ps -ax
>
>134 v2 Is+0:00.00 (getty)
>135 v3 Is+0:00.00 (getty)
>136 v4 Is+0:00.00 (getty)
>137 v5 Is+0:00.00 (getty)
() mea
> > I'd be delighted to work with you on getting this lot exposed.
>
> Sounds good - just let me know what you want me to do. I should have
> mentioned, BTW, that most of these aren't security-related (but are
> general functionality enhancements/bugfixes/etc), but some fraction are.
You know mo
On Tue, 23 Nov 1999, Mark Murray wrote:
> > I have some 500+ commit messages in my openbsd folder which are things I
> > need to investigate further for relevancy. Some way of sharing these with
> > the group, adding/removing/vetting changes which should be looked at would
> > be very useful.
>
On Tue, 23 Nov 1999, Mark Murray wrote:
> I am prepared to provide a (semi-)automatic tool that folks can
> submit their efforts to. (Yes, this is a group effort, we all need to
> get involved and donate our Copious Free Time. All the time that is
> currently invested in flamewars would be better
> Hello FreebSD'ers!
>
[snip]
>
> I have been charged with the duty of ensuring that FreeBSD gets a
> security audit that has the credibility of OpenBSD's.
>
> Consider this to be a request-for-discussion that will head us over to
> the actual work of getting it done.
[snip]
Great idea. Here
> I don't know how long it's going to take you folks to get there,
> but I'm beginning to wonder if maybe I can't hold off switching some
> machines to OpenBSD and to instead do my best to secure them under
> FreeBSD, and avoid the platform split that would otherwise result
> (and have t
At 9:05 PM +0200 1999/11/23, Mark Murray wrote:
> I have been charged with the duty of ensuring that FreeBSD gets a
> security audit that has the credibility of OpenBSD's.
You're just bound-and-determined to get me permanently drooling,
aren't you? ;-)
Seriously, I do not envy
> I have some 500+ commit messages in my openbsd folder which are things I
> need to investigate further for relevancy. Some way of sharing these with
> the group, adding/removing/vetting changes which should be looked at would
> be very useful.
I'd be delighted to work with you on getting this l
On Tue, 23 Nov 1999, Mark Murray wrote:
> 1) We need to eyeball _all_ of the code for potential security holes,
> and fix those ASAP.
>
> 2) I propose that diff(1) FreeBSD with {Open|Net}BSD, and with a
> security perspective apply those bits that look relevant and that will
> work. Who nose -
On Tue, 23 Nov 1999, Mark Murray wrote:
> Hello FreebSD'ers!
> 2) I propose that diff(1) FreeBSD with {Open|Net}BSD, and with a
> security perspective apply those bits that look relevant and that will
> work. Who nose - we may even pick up some useful featurez!
While we're on the subject of po
Hello FreebSD'ers!
[ Apologies to committers, I have Bcc'ed you to ensure you got
this; you may get two copies. ]
I have been charged with the duty of ensuring that FreeBSD gets a
security audit that has the credibility of OpenBSD's.
Consider this to be a request-for-discussion that will head
In the last episode (Nov 23), Forrest Aldrich said:
> Why does ps not show the full path on 4.0 as in 3.3? (for non-root
> users)
>
> 4.0> ps -ax
>
>134 v2 Is+0:00.00 (getty)
>135 v3 Is+0:00.00 (getty)
>136 v4 Is+0:00.00 (getty)
>137 v5 Is+0:00.00 (get
On Tuesday, 23 November 1999 at 13:15:58 -0500, Forrest Aldrich wrote:
>
> Why does ps not show the full path on 4.0 as in 3.3?
> (for non-root users)
>
> ie:
>
> 4.0> ps -ax
>
>134 v2 Is+0:00.00 (getty)
>135 v3 Is+0:00.00 (getty)
>136 v4 Is+0:00.00 (getty)
>
Why does ps not show the full path on 4.0 as in 3.3?
(for non-root users)
ie:
4.0> ps -ax
134 v2 Is+0:00.00 (getty)
135 v3 Is+0:00.00 (getty)
136 v4 Is+0:00.00 (getty)
137 v5 Is+0:00.00 (getty)
3.3> ps -ax
312 v0 Is+0:00.01 /usr/libexec/getty
In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: The problem is that the ex0 or ie0 driver, I'm not sure which,
: hoses the 3com card such that the ep driver cannot read the
: serial eeprom.
I've often had to disable the ex driver when I've had cards at 0x300
in order to make the instal
On Mon, 22 Nov 1999, Jason Evans wrote:
> Walnut Creek has hired me as a full time employee to work primarily on
> improving and expanding FreeBSD's threads support. This is very exciting
> to me, and I hope my work will be of benefit the FreeBSD community.
[insert large amounts of cheering an
> Works like a charm. Two more I've encountered:
>
> lynx:
> libncurses.so.3
> libmytinfo.so.2
Thanks! I've added them to my list. I'm going to populate compat3x from
3.4-RELEASE. So we aren't too far off.
--
-- David([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECT
On Tue, 23 Nov 1999, Peter Wemm wrote:
> I'm pretty sure it's this commit to i386/machdep.c:
> ===
> revision 1.377
> date: 1999/11/21 14:46:43; author: pho; state: Exp; lines: +5 -5
> Moved useracc() to top of sigreturn as to avoid panic
> caused by invalid arguments to rutine.
>
> Reviewed
1 - 100 of 108 matches
Mail list logo
