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
> 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
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
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
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
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
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
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
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
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,
> >
> 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
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.
>
> >
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
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
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
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
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
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
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
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
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.
>
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
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
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
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
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
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
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
> >>
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
+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
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
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
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
> 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
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
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
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
>>>
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
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
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
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
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
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
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
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
> 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
>
> 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
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
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
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
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
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.
>
>
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
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.
>
>
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
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,
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
>
On Thu, Dec 31, 2020 at 09:25:08PM -0500, grarpamp wrote:
> > There is already HTTPS to protect the "authenticity" of the magnet
> > link.
>
> No. FreeBSD fails to publish signed fingerprints of their TLS pubkeys,
> therefore users can't pin them down, therefore any MITM can bypass
> CA game and
> There is already HTTPS to protect the "authenticity" of the magnet
> link.
No. FreeBSD fails to publish signed fingerprints of their TLS pubkeys,
therefore users can't pin them down, therefore any MITM can bypass
CA game and MITM attack users at will, feed them bogus infohash,
isos, git repo
On Thu, 31 Dec 2020 11:39:08 -0800
John-Mark Gurney wrote:
> grarpamp wrote this message on Wed, Dec 30, 2020 at 00:55 -0500:
> > > signatures of the magnet links
> >
> > Signing torrent.asc, with stronger or even same hash as BT
> > protocol, still serve purpose of authenticate torrent file
grarpamp wrote this message on Wed, Dec 30, 2020 at 00:55 -0500:
> > signatures of the magnet links
>
> Signing torrent.asc, with stronger or even same hash as BT
> protocol, still serve purpose of authenticate torrent file back
> to a signer to the degree therein, caveat their platform security,
>> SHA-256 arrives, if you look at the git history.
> git's SHA-256 [...] requiring a super new git version to even test it out.
It's "in" current release 2.30.0 and before, duly caveated as experimental
and not fully featured yet...
git-init(1)
--object-format=
Specify the
On 2020-12-29 20:59, Chris wrote:
On 2020-12-29 16:46, John-Mark Gurney wrote:
Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100:
|SolarWinds supply chain attack, being able to smuggle a modified file
|into a git repo, say an OS's build server, such that the tools don't
On 2020-12-29 16:46, John-Mark Gurney wrote:
Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100:
|SolarWinds supply chain attack, being able to smuggle a modified file
|into a git repo, say an OS's build server, such that the tools don't
|know the tree is modified is a
Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100:
> |SolarWinds supply chain attack, being able to smuggle a modified file
> |into a git repo, say an OS's build server, such that the tools don't
> |know the tree is modified is a real problem...
>
> SHA-256 arrives, if
John-Mark Gurney wrote in
<20201229011939.gu31...@funkthat.com>:
|Steffen Nurpmeso wrote this message on Wed, Dec 23, 2020 at 17:24 +0100:
|>|Then there's also the point that the repo is (looks like it) using
|>|SHA-1 hashes, which are effectively broken, so depending upon them
|>|to validate
On Mon, Dec 28, 2020, 6:19 PM John-Mark Gurney wrote:
> Steffen Nurpmeso wrote this message on Wed, Dec 23, 2020 at 17:24 +0100:
> > |Then there's also the point that the repo is (looks like it) using
> > |SHA-1 hashes, which are effectively broken, so depending upon them
> > |to validate the
Steffen Nurpmeso wrote this message on Wed, Dec 23, 2020 at 17:24 +0100:
> |Then there's also the point that the repo is (looks like it) using
> |SHA-1 hashes, which are effectively broken, so depending upon them
> |to validate the tree is questionable anyways.
>
> git uses the hardened SHA-1
Kurt Jaeger wrote this message on Wed, Dec 23, 2020 at 13:15 +0100:
> Hi!
>
> > It's also hard to collect ALL the keys of the devs at any point in
> > time to decide if that key is authorized to sign a commit in the
> > repo...
>
> We do have most of the keys in docs/share/pgpkeys/ plus history.
1 - 100 of 2974 matches
Mail list logo
