Upstream OpenSSH has been working on deprecating DSA keys for some
time, and I intend to follow suit in FreeBSD.
>From the OpenSSH 9.8p1 release notes:
===
OpenSSH has disabled DSA keys by default since 2015 but has retained
run-time optional support for them. DSA was the only mandatory-to-
imple
On Sat, Feb 01, 2025 at 06:06:27AM -0800, Rick Macklem wrote:
R> You might want to put an entry in UPDATING noting that the daemons
R> need to be upgraded with the kernel.
Of course I did :)
Short update on the resource leaks. The patch that reduces refcount on
the back channel proved to be inco
On Tue, Jan 21, 2025 at 10:27 PM Gleb Smirnoff wrote:
>
> CAUTION: This email originated from outside of the University of Guelph. Do
> not click links or open attachments unless you recognize the sender and know
> the content is safe. If in doubt, forward suspicious emails to
> ith...@uoguelph
On Tue, Jan 28, 2025 at 09:14:00PM -0800, Gleb Smirnoff wrote:
T> Second, with the patch the M_RPC leak count for me is 2. And I found that
these
T> two items are basically is a clnt_vc that belongs to a closed connection:
T>
T> f80029614a80 tcp4 0 0 10.6.6.9.772 10.6.6.9.204
On Mon, Jan 27, 2025 at 06:10:42PM -0800, Rick Macklem wrote:
R> I think I've found a memory leak, but it shouldn't be a show stopper.
R>
R> What I did on the NFS client side is:
R> # vmstat -m | fgrep -i rpc
R> # mount -t nfs -o nfsv4,tls nfsv4-server:/ /mnt
R> # ls --lR /mnt
R> --> Then I networ
On Tue, Jan 21, 2025 at 10:27 PM Gleb Smirnoff wrote:
>
> CAUTION: This email originated from outside of the University of Guelph. Do
> not click links or open attachments unless you recognize the sender and know
> the content is safe. If in doubt, forward suspicious emails to
> ith...@uoguelph
On Sun, Jan 26, 2025 at 1:44 PM Rick Macklem wrote:
>
> On Tue, Jan 21, 2025 at 10:27 PM Gleb Smirnoff wrote:
> >
> > CAUTION: This email originated from outside of the University of Guelph. Do
> > not click links or open attachments unless you recognize the sender and
> > know the content is s
On Tue, Jan 21, 2025 at 10:27 PM Gleb Smirnoff wrote:
>
> CAUTION: This email originated from outside of the University of Guelph. Do
> not click links or open attachments unless you recognize the sender and know
> the content is safe. If in doubt, forward suspicious emails to
> ith...@uoguelph
On Thu, Jan 23, 2025 at 02:42:54PM -0800, Rick Macklem wrote:
R> > The code is posted on phabricator, reviews D48547 through D48552.
R> > Reviewers are very welcome!
R> >
R> > I share my branch on Github. It is usually rebased on today's CURRENT:
R> >
R> > https://github.com/glebius/FreeBSD/commits
On Tue, Jan 21, 2025 at 10:27 PM Gleb Smirnoff wrote:
>
> CAUTION: This email originated from outside of the University of Guelph. Do
> not click links or open attachments unless you recognize the sender and know
> the content is safe. If in doubt, forward suspicious emails to
> ith...@uoguelph
Hi,
TLDR version:
users of NFS with Kerberos (e.g. running gssd(8)) as well as users of NFS with
TLS (e.g. running rpc.tlsclntd(8) or rpc.tlsservd(8)) as well as users of
network lock manager (e.g. having 'options NFSLOCKD' and running rpcbind(8))
are affected. You would need to recompile & rei
Hi all,
The FreeBSD Foundation, sponsored by the Sovereign Tech Agency, is funding
work this year which will be affecting the FreeBSD build process, and release
building in particular. The main goal is to allow the entire release process
to run without special privileges (aka root); subsidiary g
On Mon, 17 Jun 2024 at 11:16, Michael Gmelin wrote:
>
> Hi Ed,
>
> In case there is no EN, what is the process to add information about
> issues like this to the release notes? Something like "known issues",
> which those of us who read the release notes can stumble over and check?
Great question
> On 17. Jun 2024, at 20:34, Shawn Webb wrote:
>
> On Mon, Jun 17, 2024 at 10:54:29AM -0400, Ed Maste wrote:
>> It is currently possible to specify an IPv4 address without a
>> netmask/width to ifconfig or in rc.conf, e.g.:
>>
>>ifconfig_igb0="192.168.0.2"
>>
>> phk recently discovered[
On Mon, Jun 17, 2024 at 10:54:29AM -0400, Ed Maste wrote:
> It is currently possible to specify an IPv4 address without a
> netmask/width to ifconfig or in rc.conf, e.g.:
>
> ifconfig_igb0="192.168.0.2"
>
> phk recently discovered[1] that ifconfig chose a poor netmask/width
> when none was sp
On Mon, 17 Jun 2024 10:54:29 -0400
Ed Maste wrote:
> It is currently possible to specify an IPv4 address without a
> netmask/width to ifconfig or in rc.conf, e.g.:
>
> ifconfig_igb0="192.168.0.2"
>
> phk recently discovered[1] that ifconfig chose a poor netmask/width
> when none was spec
It is currently possible to specify an IPv4 address without a
netmask/width to ifconfig or in rc.conf, e.g.:
ifconfig_igb0="192.168.0.2"
phk recently discovered[1] that ifconfig chose a poor netmask/width
when none was specified. This was not an intentional change in
defaults but rather a bug
Hi everyone,
We currently publish a number of VM images on download.freebsd.org:
* Generic VM images, with URLs like
https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/amd64/20240613/FreeBSD-15.0-CURRENT-amd64-ufs-20240613-bb53f071e85a-270741.qcow2.xz
https://download.freebsd.org/snap
OK. I have pushed 4 series of commits. (1) remove sccs IDs by and large (a
couple of exceptions where @(#) didn't mark an SCCS id). (2) remove if 0'd
copyright strings. (3) Mechanical changes to most of the tree to cleanup
style divots after these changes (and the $FreeBSD$ removal) (4) cdefs.h
cle
On Fri, Nov 17, 2023 at 11:00:07AM +0100, Olivier Certner wrote:
> Hi Glen,
>
> > I also agree we cannot prevent people from downloading the images,
> > installers, whatever before the announcement. That is the lovely race
> > condition with which we have to live at the moment.
>
> Yes, and give
Glen Barber wrote:
> No. It merely suggests the release is not officially official yet.
Ok. Thanks for the clarification.
Jamie.
Hi Glen,
> I also agree we cannot prevent people from downloading the images,
> installers, whatever before the announcement. That is the lovely race
> condition with which we have to live at the moment.
Yes, and given that, I don't think you did anything wrong.
It seems that the race is the sa
On Thu, Nov 16, 2023 at 09:22:52PM +, Jamie Landeg-Jones wrote:
> > Ok. I do not know what exactly is your point, but releases are never
> > official until there is a PGP-signed email sent. The email is intended
> > for the general public of consumers of official releases, not "yeah,
> > but"
> Ok. I do not know what exactly is your point, but releases are never
> official until there is a PGP-signed email sent. The email is intended
> for the general public of consumers of official releases, not "yeah,
> but"s.
Foe a recent new build, I just went to the ftp site to grab the latest r
On Thu, Nov 16, 2023 at 12:07:36AM -0500, Glen Barber wrote:
> And if there is a reason to reissue a release, the update will reflect such.
>
> So to answer your latter question, yes. Unless it needs to be replaced.
>
> Glen
> Sent from my phone.
> Please excuse my brevity and/or typos.
>
> > O
And if there is a reason to reissue a release, the update will reflect such.
So to answer your latter question, yes. Unless it needs to be replaced.
Glen
Sent from my phone.
Please excuse my brevity and/or typos.
> On Nov 15, 2023, at 11:38 PM, The Doctor wrote:
>
> On Thu, Nov 16, 2023 at 1
Thank you for that.
Glen
Sent from my phone.
Please excuse my brevity and/or typos.
> On Nov 15, 2023, at 11:17 PM, Rich Reynolds wrote:
>
> On 11/15/23 20:19, Pete Wright wrote:
>>> On 11/15/23 16:30, Glen Barber wrote:
>>> The alternative would be to say nothing at all.
>>>
>>> Either way,
On Thu, Nov 16, 2023 at 12:30:30AM +, Glen Barber wrote:
> On Wed, Nov 15, 2023 at 08:39:39AM -0800, John Baldwin wrote:
> > On 11/14/23 8:52 PM, Glen Barber wrote:
> > > On Tue, Nov 14, 2023 at 08:10:23PM -0700, The Doctor wrote:
> > > > On Wed, Nov 15, 2023 at 02:27:01AM +, Glen Barber wr
On Wed, Nov 15, 2023 at 07:19:39PM -0800, Pete Wright wrote:
>
>
> On 11/15/23 16:30, Glen Barber wrote:
> > The alternative would be to say nothing at all.
> >
> > Either way, it is a productivity, communication drain. It is
> > a lose-lose situation no matter how one looks at it given the abo
On 11/15/23 16:30, Glen Barber wrote:
The alternative would be to say nothing at all.
Either way, it is a productivity, communication drain. It is
a lose-lose situation no matter how one looks at it given the above
context. We either get chastised for being "too open" into insights
delaying
On Wed, Nov 15, 2023 at 08:39:39AM -0800, John Baldwin wrote:
> On 11/14/23 8:52 PM, Glen Barber wrote:
> > On Tue, Nov 14, 2023 at 08:10:23PM -0700, The Doctor wrote:
> > > On Wed, Nov 15, 2023 at 02:27:01AM +, Glen Barber wrote:
> > > > On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wro
On 11/14/23 8:52 PM, Glen Barber wrote:
On Tue, Nov 14, 2023 at 08:10:23PM -0700, The Doctor wrote:
On Wed, Nov 15, 2023 at 02:27:01AM +, Glen Barber wrote:
On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote:
On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote:
We are stil
Well, today is your yesterday, so we might not be ready for another more
tomorrows your time, yesterdays, my time. Or something.
Glen
Sent from my phone.
Please excuse my brevity and/or typos.
> On Nov 15, 2023, at 2:39 AM, matti k wrote:
>
> On Wed, 15 Nov 2023 04:52:31 +
> Glen Barber
On Wed, 15 Nov 2023 04:52:31 +
Glen Barber wrote:
> > > Ok. I do not know what exactly is your point, but releases are
> > > never official until there is a PGP-signed email sent. The email
> > > is intended for the general public of consumers of official
> > > releases, not "yeah, but"s.
>
On Tue, Nov 14, 2023 at 08:10:23PM -0700, The Doctor wrote:
> On Wed, Nov 15, 2023 at 02:27:01AM +, Glen Barber wrote:
> > On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote:
> > > On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote:
> > > > We are still waiting for a few (non-c
On Wed, Nov 15, 2023 at 02:27:01AM +, Glen Barber wrote:
> On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote:
> > On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote:
> > > We are still waiting for a few (non-critical) things to complete before
> > > the announcement of 14.0-RE
On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote:
> On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote:
> > We are still waiting for a few (non-critical) things to complete before
> > the announcement of 14.0-RELEASE will be ready.
> >
> > It should only be another day or so bef
On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote:
> We are still waiting for a few (non-critical) things to complete before
> the announcement of 14.0-RELEASE will be ready.
>
> It should only be another day or so before these things complete.
>
> Thank you for your understanding.
>
I
We are still waiting for a few (non-critical) things to complete before
the announcement of 14.0-RELEASE will be ready.
It should only be another day or so before these things complete.
Thank you for your understanding.
Glen
On behalf of: re@
signature.asc
Description: PGP signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
No email was sent for the branch commit, presumably because I pushed the
branch and did subsequent changes (i.e., version numbers, etc.)
afterward.
The stable/14 branch has been created, from where the remainder of the
14.0 series will live.
Glen
O
Greetings,
I've just pushed the results that remove 31,035 instances of $FreeBSD$ from
the main branch.
>From this point out, we are effectively done with $FreeBSD$, though there's
4 places where $FreeBSD$ still exists in the tree:
(1) In the contrib area, we have 621 remaining. I didn't remove a
On Fri, 5 May 2023 at 09:38, Ed Maste wrote:
>
> FreeBSD supports up to 256 CPU cores in the default kernel configuration
> (on Tier-1 architectures). Systems with more than 256 cores are
> available now, and will become increasingly common over FreeBSD 14’s
> lifetime. The FreeBSD Foundation is
I have just pushed this update into -current. It compiles and boots for me.
It should be a giant nop. I plan on MFCing this in a few days unless
there's unanticipated turbulence.
I have not updated the SIM drivers because most of the u_intXX_t use in
these drivers are not related to CAM interfaces
Commit ed03776ca7f4 enabled the NFSD_VNET, KRPC_VNET
and KGSS_VNET macros. Kernels built with "options VIMAGE"
now have a bunch of global variables used by the NFS server
vnet'd.
It is not quite ready to run the NFS server in a vnet prison.
There are still a couple of patches in D37741 and D38371
Hi,
Commit 7344856e3a6d was a large patch that added macros
that will front end the vnet macros. These macros are null ops now,
so they should not affect semantics.
However, the code did change how things get initialized for the nfsd
and that has already caused some breakage, that I think is now
Hi,
Commits over the last couple of days and ones happening
over the next few days change the internal KPI between
the nfs modules (nfscommon.ko, nfscl.ko and nfsserver.ko).
As such, after pulling an up to date main from the git repo
you need to build all nfs modules from the new sources.
I am n
Hi,
pon., 24 sty 2022 o 20:48 Marek Zarychta
napisał(a):
>
> Hello Marcin
> W dniu 24.01.2022 o 19:43, Marcin Wojtas pisze:
> > Hi Marek,
> >
> > pon., 24 sty 2022 o 08:17 Marek Zarychta
> > napisał(a):
> >>
> >> W dniu 24.01.2022 o 07:42, Marcin Wojtas pisze:
> >>> +freebsd-stable@
> >>>
> >>>
Hello Marcin
W dniu 24.01.2022 o 19:43, Marcin Wojtas pisze:
Hi Marek,
pon., 24 sty 2022 o 08:17 Marek Zarychta
napisał(a):
W dniu 24.01.2022 o 07:42, Marcin Wojtas pisze:
+freebsd-stable@
niedz., 23 sty 2022 o 11:36 Marcin Wojtas napisał(a):
Hi,
As of 396e9f259d962 the base system bina
Hi Marek,
pon., 24 sty 2022 o 08:17 Marek Zarychta
napisał(a):
>
> W dniu 24.01.2022 o 07:42, Marcin Wojtas pisze:
> > +freebsd-stable@
> >
> > niedz., 23 sty 2022 o 11:36 Marcin Wojtas napisał(a):
> >>
> >> Hi,
> >>
> >> As of 396e9f259d962 the base system binaries are now built as
> >> positi
W dniu 24.01.2022 o 07:42, Marcin Wojtas pisze:
+freebsd-stable@
niedz., 23 sty 2022 o 11:36 Marcin Wojtas napisał(a):
Hi,
As of 396e9f259d962 the base system binaries are now built as
position-independent executable (PIE) by default, for 64-bit architectures.
Thanks to that enabling ASLR
+ freebsd-stable@, apologies for the noise.
niedz., 23 sty 2022 o 11:36 Marcin Wojtas napisał(a):
>
> Hi,
>
> As of 396e9f259d962 the base system binaries are now built as
> position-independent executable (PIE) by default, for 64-bit architectures.
> Thanks to that enabling ASLR can be done si
+freebsd-stable@
niedz., 23 sty 2022 o 11:36 Marcin Wojtas napisał(a):
>
> Hi,
>
> As of 396e9f259d962 the base system binaries are now built as
> position-independent executable (PIE) by default, for 64-bit architectures.
> Thanks to that enabling ASLR can be done simply
> by sysctls knobs whe
Hi,
As of 396e9f259d962 the base system binaries are now built as
position-independent executable (PIE) by default, for 64-bit architectures.
Thanks to that enabling ASLR can be done simply
by sysctls knobs when booting the kernel.
If you track stable/13 and normally build WITHOUT_CLEAN you'll ne
On Fri, Dec 10, 2021 at 06:35:47PM +0100, Marcin Wojtas wrote:
> Hi Daniel
>
>
> pt., 10 gru 2021 o 10:16 Daniel O'Connor napisał(a):
> >
> >
> >
> > > On 17 Nov 2021, at 09:00, Marcin Wojtas wrote:
> > > As of b014e0f15bc7 the ASLR (Address Space Layout
> > > Randomization) feature becomes ena
Hi Daniel
pt., 10 gru 2021 o 10:16 Daniel O'Connor napisał(a):
>
>
>
> > On 17 Nov 2021, at 09:00, Marcin Wojtas wrote:
> > As of b014e0f15bc7 the ASLR (Address Space Layout
> > Randomization) feature becomes enabled for the all 64-bit
> > binaries by default.
>
> Firstly, thank your for your e
> On 17 Nov 2021, at 09:00, Marcin Wojtas wrote:
> As of b014e0f15bc7 the ASLR (Address Space Layout
> Randomization) feature becomes enabled for the all 64-bit
> binaries by default.
Firstly, thank your for your efforts here, it is appreciated :)
I am finding that the lang/sdcc port is crash
As reported by Stefan Blachmann in a reply on freebsd-hackers[1],
having `options VESA` compiled into the kernel or loaded as a module
breaks suspend-resume with the nvidia driver. See PR 253733.
The default console is provided by vt(4), which does not use the
`options VESA` driver, which serves n
On Sat, 20 Nov 2021 at 20:00, Ed Maste wrote:
>
> On Thu, 18 Nov 2021 at 13:09, Li-Wen Hsu wrote:
> >
> > The mkimg ones are a bit tricky, it seems the output is changed in
> > each run. We may need a way to generate reproducible results..
>
> Hopefully fixed by 036af1053acd6cae68c5fb6bed30508f2e
On Thu, 18 Nov 2021 at 13:09, Li-Wen Hsu wrote:
>
> The mkimg ones are a bit tricky, it seems the output is changed in
> each run. We may need a way to generate reproducible results..
Hopefully fixed by 036af1053acd6cae68c5fb6bed30508f2e40be13.
> On 18 Nov 2021, at 11:43, Marcin Wojtas wrote:
> czw., 18 lis 2021 o 19:07 Li-Wen Hsu napisał(a):
>>
>>> On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas wrote:
>>>
>>> As of b014e0f15bc7 the ASLR (Address Space Layout
>>> Randomization) feature becomes enabled for the all 64-bit
>>> binaries
Hi,
czw., 18 lis 2021 o 19:07 Li-Wen Hsu napisał(a):
>
> On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas wrote:
> >
> > As of b014e0f15bc7 the ASLR (Address Space Layout
> > Randomization) feature becomes enabled for the all 64-bit
> > binaries by default.
> >
> > Address Space Layout Randomizatio
On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas wrote:
>
> As of b014e0f15bc7 the ASLR (Address Space Layout
> Randomization) feature becomes enabled for the all 64-bit
> binaries by default.
>
> Address Space Layout Randomization (ASLR) is an exploit mitigation
> technique implemented in the majori
As of b014e0f15bc7 the ASLR (Address Space Layout
Randomization) feature becomes enabled for the all 64-bit
binaries by default.
Address Space Layout Randomization (ASLR) is an exploit mitigation
technique implemented in the majority of modern operating systems.
It involves randomly positioning th
Hi,
This is a heads-up so that you are aware I'm intending to merge
clang/llvm 13.0.0 the coming weekend, e.g. somewhere between Sat
2021-11-13 and Sun 2021-11-14. The source of the merge will be
<https://github.com/DimitryAndric/freebsd-src/tree/llvm-13-update>,
which I regularly s
On Tue, Jun 8, 2021 at 7:45 PM Li-Wen Hsu wrote:
>
> Hello,
>
> As mentioned in the "OpenZFS imports, status update":
>
> https://lists.freebsd.org/archives/freebsd-git/2021-June/13.html
>
> We're going to rename the current openzfs vendor branch,
> vendor/openzfs, to vendor/openzfs/legacy
Hello,
As mentioned in the "OpenZFS imports, status update":
https://lists.freebsd.org/archives/freebsd-git/2021-June/13.html
We're going to rename the current openzfs vendor branch,
vendor/openzfs, to vendor/openzfs/legacy
and import directly the master and zfs-2.1-release branches from
On Sun, Feb 28, 2021 at 09:40:54AM -0500, Shawn Webb wrote:
> ... The point of ASLR is to combine it with W^X. Without W^X, ASLR makes
> no sense. FreeBSD recently gained a W^X implementation that requires
> opt-in. ...
I'm not plugged into the right places to catch some of these things up
front
On Sat, Feb 27, 2021 at 08:34:11PM -0800, Ihor Antonov wrote:
> >
> > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add
> > any security, except imaginary? The only purpose of it is to have a
> > check-list item ticked green.
>
> I don't know if I should parse this as sarca
On Sat, Feb 27, 2021 at 10:29:14PM -0700, Warner Losh wrote:
> On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov wrote:
>
> > >
> > > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add
> > > any security, except imaginary? The only purpose of it is to have a
> > > check-list item
> On 28. Feb 2021, at 13:27, dmilith . wrote:
>
> First of all - ALSR is designed as mitigation for external attacks,
> not internal ones (logged in user).
> Second - Linux and FreeBSD both have weak implementations in
> comparison to PAX-driven ones. Try attacking the system with
> Grsecurity
First of all - ALSR is designed as mitigation for external attacks,
not internal ones (logged in user).
Second - Linux and FreeBSD both have weak implementations in
comparison to PAX-driven ones. Try attacking the system with
Grsecurity or HardenedBSD (both use the strongest ASLR available
AFAIK).
On 2021-02-27 22:29, Warner Losh wrote:
> On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov wrote:
>
> > >
> > > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add
> > > any security, except imaginary? The only purpose of it is to have a
> > > check-list item ticked green.
> >
>
On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov wrote:
> >
> > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add
> > any security, except imaginary? The only purpose of it is to have a
> > check-list item ticked green.
>
> I don't know if I should parse this as sarcasm (or any
>
> But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add
> any security, except imaginary? The only purpose of it is to have a
> check-list item ticked green.
I don't know if I should parse this as sarcasm (or any other form of
"humor") or is a serious statement? But this does
On Fri, Feb 26, 2021 at 08:32:26PM +0100, Gordon Bergling wrote:
> On Fri, Feb 26, 2021 at 08:57:55PM +0200, Konstantin Belousov wrote:
> > On Fri, Feb 26, 2021 at 07:34:03PM +0100, Gordon Bergling wrote:
> > > On Thu, Feb 25, 2021 at 03:58:07PM -0500, Ed Maste wrote:
> > > > As of 9a227a2fd642 (ma
On Fri, Feb 26, 2021 at 08:57:55PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 26, 2021 at 07:34:03PM +0100, Gordon Bergling wrote:
> > On Thu, Feb 25, 2021 at 03:58:07PM -0500, Ed Maste wrote:
> > > As of 9a227a2fd642 (main-n245052) base system binaries are now built
> > > as position-independ
On Fri, Feb 26, 2021 at 07:34:03PM +0100, Gordon Bergling wrote:
> On Thu, Feb 25, 2021 at 03:58:07PM -0500, Ed Maste wrote:
> > As of 9a227a2fd642 (main-n245052) base system binaries are now built
> > as position-independent executable (PIE) by default, for 64-bit
> > architectures. PIE executable
On Thu, Feb 25, 2021 at 03:58:07PM -0500, Ed Maste wrote:
> As of 9a227a2fd642 (main-n245052) base system binaries are now built
> as position-independent executable (PIE) by default, for 64-bit
> architectures. PIE executables are used in conjunction with address
> randomization as a mitigation fo
On Thu, Feb 25, 2021 at 09:22:43PM -0500, Ed Maste wrote:
> On Thu, 25 Feb 2021 at 19:23, John Kennedy wrote:
> >
> > Not sure if Ed Maste just wants to make sure that all the executables
> > are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that
> > he knows about.
>
> The
On 26 Feb 2021, at 03:22, Ed Maste wrote:
>
> On Thu, 25 Feb 2021 at 19:23, John Kennedy wrote:
>>
>> Not sure if Ed Maste just wants to make sure that all the executables
>> are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that
>> he knows about.
>
> The issue is that w
On Thursday, 25 February 2021 at 21:22:43 -0500, Ed Maste wrote:
> On Thu, 25 Feb 2021 at 19:23, John Kennedy wrote:
>>
>> Not sure if Ed Maste just wants to make sure that all the executables
>> are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that
>> he knows about.
>
> T
On Thu, 25 Feb 2021 at 19:23, John Kennedy wrote:
>
> Not sure if Ed Maste just wants to make sure that all the executables
> are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that
> he knows about.
The issue is that without a clean build you may have some .o files
left aro
On Thu, 25 Feb 2021 at 18:10, Greg 'groggy' Lehey wrote:
>
> This details worries me. How compatible are PIE executables with
> non-PIE executables? Can I run PIE executables on older systems? Can
> I run older executables on a PIE system?
There is no issue mixing PIE and non-PIE binaries, and
On Fri, Feb 26, 2021 at 10:10:28AM +1100, Greg 'groggy' Lehey wrote:
> On Thursday, 25 February 2021 at 15:58:07 -0500, Ed Maste wrote:
> > As of 9a227a2fd642 (main-n245052) base system binaries are now built
> > as position-independent executable (PIE) by default, for 64-bit
> > architectures. ...
On Thursday, 25 February 2021 at 15:58:07 -0500, Ed Maste wrote:
> As of 9a227a2fd642 (main-n245052) base system binaries are now built
> as position-independent executable (PIE) by default, for 64-bit
> architectures. PIE executables are used in conjunction with address
> randomization as a mitiga
As of 9a227a2fd642 (main-n245052) base system binaries are now built
as position-independent executable (PIE) by default, for 64-bit
architectures. PIE executables are used in conjunction with address
randomization as a mitigation for certain types of security
vulnerabilities.
If you track -CURREN
Typo:
On Mon, Jan 4, 2021 at 5:25 PM Conrad Meyer wrote:
> SHA1 has always, by design, been vulnerable to a 2^80 resource attack :-).
2^160 for a specific hash. 2^80 if you're just trying to find any collision.
___
freebsd-current@freebsd.org mailing
On Mon, Jan 4, 2021 at 1:44 PM Ryan Stone wrote:
> FWIW, a coworker of mine had a little hobby of introducing commits
> into our internal repro that had hashes that all started with
> deadc0de. As I understand it, it was able to do this by adding an
> bogus attribute with the right value to the c
On Mon, Jan 4, 2021 at 3:44 PM Poul-Henning Kamp wrote:
> Shattered is less impressive when you take into account that you
> can stuff as much much garbage into a PDF file as you need, without
> affecting the files normal function.
>
> Compact data formats, formats which leave no wiggle-room and d
John-Mark Gurney writes:
> SHAttered[1] (2017) created two valid PDF documents which had the same
> SHA-1 hash. The issue was that they were able to choose the entire
> document.
Shattered is less impressive when you take into account that you
can stuff as much much garbage into a PDF f
RW wrote this message on Fri, Jan 01, 2021 at 16:56 +:
> On Thu, 31 Dec 2020 21:25:08 -0500
> grarpamp wrote:
>
> > > Is there any reason to think [bittorrent] insecure?
> >
> > Cost under $50k of compute to break sha-1,
>
> AFAIK you cannot break SHA-1 in the sense of creating data that
>> Though it can help attribute that to a source,
Meaning to source 'account', vs say weak old CVSROOT
that any could text edit on 200 account box, claim bitrot, etc.
Whether inspiration came from the pet dog's bug report
is moot, more secure systems narrow into accounts that
would then be examine
grarpamp writes:
> > No amount of cryptography can or will protect against that.
>
> Though it can help attribute that to a source,
No.
You would end up with the committer saying "it came in as a bug-report,
I looked at it, and it looked sensible so I committed it."
Unless you are goin
Folks, please change the Subject: line here. This has now become a
thread of only tangiental interest to a typical FreeBSD developer
(in this case, typified by me :-) )
mcl
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/l
> No amount of cryptography can or will protect against that.
Though it can help attribute that to a source,
else ignore rainbow books and go back to telnet,
root password 'root', CVS, no backups, logs, etc.
> As interesting as this thread has been (not!)
Contrare.
Equally as interesting as thre
As interesting as this thread has been (not!), let me remind everybody
that the cheapest, easiest and most efficient and profitable way
for a Nation State Actor to trojan the FreeBSD code-base, is to
assign an employee to a deniable job, and have them become a FreeBSD
committer.
No amount of crypt
On Sat, Jan 02, 2021 at 08:37:14AM +0800, Li-Wen Hsu wrote:
> On Sat, Jan 2, 2021 at 4:25 AM Christian Weisgerber
> wrote:
> >
> > On 2021-01-01, Shawn Webb wrote:
> >
> > > This is why I asked FreeBSD to provide anonymous read-only ssh://
> > > support for git. I'm very grateful they support it
On Sat, Jan 2, 2021 at 4:25 AM Christian Weisgerber wrote:
>
> On 2021-01-01, Shawn Webb wrote:
>
> > This is why I asked FreeBSD to provide anonymous read-only ssh://
> > support for git. I'm very grateful they support it.
> >
> > One thing that I need to do with the HardenedBSD infrastructure i
On Thu, 31 Dec 2020 21:25:08 -0500
grarpamp wrote:
> > Is there any reason to think [bittorrent] insecure?
>
> Cost under $50k of compute to break sha-1,
AFAIK you cannot break SHA-1 in the sense of creating data that
matches a specific hash. What you can do is create a collision between
two
On 2021-01-01, Shawn Webb wrote:
> This is why I asked FreeBSD to provide anonymous read-only ssh://
> support for git. I'm very grateful they support it.
>
> One thing that I need to do with the HardenedBSD infrastructure is
> publish on our site the ssh pubkeys of the server (both RSA and
> ed2
1 - 100 of 3205 matches
Mail list logo
