of really old ISA NICs that only do 10Mbps).
Even in that case, the code will always live on in the source code control
repository's history. That means it can always be resurrected if someone shows
up who will maintain it and keep it up to date.
At this point I think this
int optval, s;
s = socket(PF_INET, SOCK_STREAM, 0);
if (s < 0)
err(1, "socket");
optval = 0;
if (setsockopt(s, IPPROTO_TCP, TCP_NOPUSH, &optval, sizeof(optval)) < 0)
err(1, "setsockopt");
and se
On Friday, January 28, 2011 12:38:22 pm Tom Judge wrote:
> On 01/28/2011 11:09 AM, John Baldwin wrote:
> > On Friday, January 28, 2011 11:08:37 am Tom Judge wrote:
> >> On 01/28/2011 08:29 AM, Tom Judge wrote:
> >>>
> >>> Has anyone looked at this:
&
On Thursday, December 29, 2011 1:44:01 pm Xin Li wrote:
> On 12/29/11 10:43, John Baldwin wrote:
> > On Thursday, December 29, 2011 1:26:17 pm Xin Li wrote:
> >> On 12/29/11 06:39, John Baldwin wrote:
> >>> Can you give some more details on why ftpd is triggerin
On Thursday, December 29, 2011 1:26:17 pm Xin Li wrote:
> On 12/29/11 06:39, John Baldwin wrote:
> > Can you give some more details on why ftpd is triggering a dlopen
> > inside of the chroot? It would appear that that is unrelated to
> > helper programs (since setting a
u give some more details on why ftpd is triggering a dlopen inside of
the chroot? It would appear that that is unrelated to helper programs (since
setting a flag in libc in ftpd can't possibly affect helper programs ability
to use dlopen() from within libc).
--
John Baldwin
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
On Thursday, December 29, 2011 2:10:37 pm Xin LI wrote:
> On Thu, Dec 29, 2011 at 11:00 AM, John Baldwin wrote:
> > On Thursday, December 29, 2011 1:44:01 pm Xin Li wrote:
> >> On 12/29/11 10:43, John Baldwin wrote:
> >> > On Thursday, December 29, 2011 1:26:17 pm
On Thursday, December 29, 2011 3:30:23 pm Xin Li wrote:
> On 12/29/11 11:35, John Baldwin wrote:
> > On Thursday, December 29, 2011 2:10:37 pm Xin LI wrote:
> >> On Thu, Dec 29, 2011 at 11:00 AM, John Baldwin
> >> wrote:
> >>> On Thursday, December 29, 201
Is the correct
> interpretation that FreeBSD/amd64 running on Intel CPUs is the vulnerable
> combination?
It is only know that AMD CPUs are safe. It is not known if non-AMD, non-Intel
CPUs (e.g. the 64-bit capable VIA CPUs) are vulnerable.
--
John Baldwin
___
stent.
However, the fix is functionally correct in this case.
--
John Baldwin
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
> > generator, but it's easy to fix it, so it should be fixed.
> >
> > ___
> > freebsd-security@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-security
> > To u
from the outside, I have to say this much:
this is a really rediculous argument that works both ways. Just because we
don't have a documented vulnerability doesn't mean it doesn't exist either.
Also, you are clearly wrong about /dev/random dropping input and refuse to
ad
* Set ih_need for this handler so that if the ithread is already
* running it will execute this handler on the next pass. Otherwise,
--
John Baldwin
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
intrhook's often go out and do things that take a
variable amount of time (poking hardware, waiting for interrupts, etc.).
That means that timing any such drivers from single user mode will likely
give you more variable attach() times than would occur during boot.
--
John Baldwin
__
uhub0
uhub3
uhub4
ukbd0
In this portion of my desktop's device tree, all of the devices listed will
include the time of ukbd0's attach in their respective attach times.
--
John Baldwin
___
free
s going to switch
to pulling from SVN (if it hasn't already), but you still have the issue
of knowing how you can trust the repository being used for snapshots.
--
John Baldwin
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
o with malloc zeroing, etc. FreeBSD
definitely does do this. However, the "right" answer is probably that you
will have to pay to have the version of FreeBSD you are currently using
audited.
--
John Baldwin
___
freebsd-security@freebsd.
e built my own v1 openssh client.
I think Ian is suggesting that a port is possible so long as someone will
agree to maintain it. That is, if you will create and maintain the port
then there will be a centralized package for it. The only trick is that
someone who cares about ss
n less fragile) if we bound keys to sessions
and required keys during session creation.
You can see my WIP here:
https://github.com/freebsd/freebsd/compare/master...bsdjhb:ocf_rework
--
John Baldwin
plication tries to use directly (and
the application is linked against 3.0.0), but I'm not sure how common
that situation will be in practice. OpenSSL isn't libc where you have
issues with malloc/free crossing this sort of boundary.
--
John Baldwin
_
On 12/12/20 4:57 PM, John-Mark Gurney wrote:
> John Baldwin wrote this message on Sat, Dec 12, 2020 at 11:40 -0800:
>> On 12/10/20 10:46 PM, John-Mark Gurney wrote:
>>> I have not heard if OpenSSL has bother to address the breakage of
>>> /dev/crypto that also recently
On 12/14/20 4:37 PM, Konstantin Belousov wrote:
> On Mon, Dec 14, 2020 at 11:44:27AM -0800, John Baldwin wrote:
>> If we import 3.0.0 into, say, 13.2, then when 13.0/13.1 are EOLd we are
>> no longer having to maintain 1.1.1 in 13. If people want to keep older
>> applications
22 matches
Mail list logo
