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
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
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
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
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
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
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
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
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
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 M
> 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 tof
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 ba
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 giv
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 re
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 you
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 f
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.
> We do have most of the keys in docs/share/pgpkeys/ plus history.
https://git.kernel.org/pub/scm/docs/kernel/ksmap
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo
Am 23.12.20 um 21:55 schrieb Ulrich Spörlein:
> On Wed, 2020-12-23 at 12:19:47 -0800, John Kennedy wrote:
>> On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote:
>>> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
>>> > The FreeBSD project will be moving it's source repo from
On Wed, 2020-12-23 at 12:19:47 -0800, John Kennedy wrote:
On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote:
On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
> The FreeBSD project will be moving it's source repo from subversion to git
> starting this this weekend. The docs
On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote:
> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
> > The FreeBSD project will be moving it's source repo from subversion to git
> > starting this this weekend. The docs repo was moved 2 weeks ago. The ports
> > repo will mo
On 23/12/20 15:20, Michael Grimm wrote:
Renato Botelho wrote:
If you want to switch to a different already existing branch, as svn switch
does, you should look at git-checkout.
It can be a bit expensive due to the size of src repository so if you do work
on multiple branches too often you c
Renato Botelho wrote:
> If you want to switch to a different already existing branch, as svn switch
> does, you should look at git-checkout.
>
> It can be a bit expensive due to the size of src repository so if you do work
> on multiple branches too often you can improve it using git-worktree.
Warner Losh wrote:
> On Wed, Dec 23, 2020 at 7:32 AM Michael Grimm wrote:
>> With svn I used:
>>svn switch svn://svn.freebsd.org/base/stable/NEW /usr/src
>>
>> For git I found:
>>git branch -m stable/OLD stable/NEW
>>or
>>git branch -M stable/OLD stable/NEW
>
>
On Wed, Dec 23, 2020 at 7:32 AM Michael Grimm wrote:
> Hi,
>
> Warner Losh wrote:
>
> > The FreeBSD project will be moving it's source repo from subversion to
> git
> > starting this this weekend.
>
> First of all I'd like to thank all those involved in this for their
> efforts.
>
> Following
>
On Tue, Dec 22, 2020 at 06:32:43PM -0800, John-Mark Gurney wrote:
> Steffen Nurpmeso wrote this message on Fri, Dec 18, 2020 at 19:28 +0100:
> > Brooks Davis wrote in
> > <20201218175241.ga72...@spindle.one-eyed-alien.net>:
> > |On Thu, Dec 17, 2020 at 05:53:20PM -0800, Thomas Mueller wrote:
> >
On Wed, Dec 23, 2020 at 3:35 AM Marek Zarychta <
zarych...@plan-b.pwste.edu.pl> wrote:
> W dniu 17.12.2020 o 01:46, Warner Losh pisze:
> > Greetings,
> >
> > The FreeBSD project will be moving it's source repo from subversion to
> git
> > starting this this weekend. The docs repo was moved 2 weeks
John-Mark Gurney wrote in
<20201223023242.gg31...@funkthat.com>:
|Steffen Nurpmeso wrote this message on Fri, Dec 18, 2020 at 19:28 +0100:
|> Brooks Davis wrote in
|> <20201218175241.ga72...@spindle.one-eyed-alien.net>:
|>|On Thu, Dec 17, 2020 at 05:53:20PM -0800, Thomas Mueller wrote:
...
On 23.12.2020 18:04, Lev Serebryakov wrote:
On 23.12.2020 17:32, Michael Grimm wrote:
git-branch(1):
With a -m or -M option, will be renamed to .
If
==
had a corresponding reflog, it is renamed to match
On 23.12.2020 17:32, Michael Grimm wrote:
git-branch(1):
With a -m or -M option, will be renamed to . If
==
had a corresponding reflog, it is renamed to match
, and a reflog entry is created to remembe
On 23/12/20 11:32, Michael Grimm wrote:
Hi,
Warner Losh wrote:
The FreeBSD project will be moving it's source repo from subversion to git
starting this this weekend.
First of all I'd like to thank all those involved in this for their efforts.
Following https://github.com/bsdimp/freebsd-git
Hi,
Warner Losh wrote:
> The FreeBSD project will be moving it's source repo from subversion to git
> starting this this weekend.
First of all I'd like to thank all those involved in this for their efforts.
Following https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md
form yo
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.
> Like if a dev starts in 2021, any commits made by that
> dev prior to 2021 shou
1 - 100 of 2651 matches
Mail list logo
