Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 given that, I don't think you did anything wrong. > > It seems that the race is the same for freebsd-update(8), according to "The > Doctor". But maybe in this case it is easier to fix, perhaps if installing > the metadata signaling the new release to it can be delayed, by contrast with > big files containing the actual data (I don't know how freebsd-update(8) > works, so this is just a guess). > > > The alternative would be to say nothing at all. > > I really hope you and re@ will never choose this way. > > > 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 an official announcement, or for being "not open enough" when > > there is silence from RE when a release does not meet its scheduled > > announcement date. > > IMHO, a delay should always be announced (perhaps unless it's only a few > days). If it is too hard to decide on the right level of details, then only > mention that some (potential or verified) problem is being looked upon, but > don't let that prevent you from communicating. > > As for people saying that they have already installed the "release", I'd > suggest to have some text on the website (https://www.freebsd.org/releng/ > perhaps) explaining that images on mirrors can appear in advance of release > announcements and that they should not be considered as official until the > official mail is sent, and just kindly point them to it. I hope this can > contribute to at least attenuating the drain you're experiencing. > > Regards. > > -- > Olivier Certner > > just a suggestion for the future is that to have some sort of gpg/gpg check in freebsd-update . -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen Lest we forget 11 Nov 2023 Beware https://mindspring.com
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
Glen Barber wrote: > No. It merely suggests the release is not officially official yet. Ok. Thanks for the clarification. Jamie.
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 same for freebsd-update(8), according to "The Doctor". But maybe in this case it is easier to fix, perhaps if installing the metadata signaling the new release to it can be delayed, by contrast with big files containing the actual data (I don't know how freebsd-update(8) works, so this is just a guess). > The alternative would be to say nothing at all. I really hope you and re@ will never choose this way. > 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 an official announcement, or for being "not open enough" when > there is silence from RE when a release does not meet its scheduled > announcement date. IMHO, a delay should always be announced (perhaps unless it's only a few days). If it is too hard to decide on the right level of details, then only mention that some (potential or verified) problem is being looked upon, but don't let that prevent you from communicating. As for people saying that they have already installed the "release", I'd suggest to have some text on the website (https://www.freebsd.org/releng/ perhaps) explaining that images on mirrors can appear in advance of release announcements and that they should not be considered as official until the official mail is sent, and just kindly point them to it. I hope this can contribute to at least attenuating the drain you're experiencing. Regards. -- Olivier Certner
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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"s. > > Foe a recent new build, I just went to the ftp site to grab the latest rc, > only to see 14.0-release there, so I grabbed and installed that, many > hours before your original mail went out. > > No biggy, I generally track stable, but does this mean we can't rely > on the download sites without checking out the lists first? It's not > like I was plaing sneaky by doing "guess the URL" or anything like that. > No. It merely suggests the release is not officially official yet. Glen signature.asc Description: PGP signature
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
> 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 rc, only to see 14.0-release there, so I grabbed and installed that, many hours before your original mail went out. No biggy, I generally track stable, but does this mean we can't rely on the download sites without checking out the lists first? It's not like I was plaing sneaky by doing "guess the URL" or anything like that. Jamie
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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. > > > On Nov 15, 2023, at 11:38 PM, The Doctor wrote: > > > > ???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 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-RELEASE will be ready. > > It should only be another day or so before these things complete. > > Thank you for your understanding. > > >>> > >>> I always just installed my copy. > >>> > >> > >> 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. > >> > > > > Howver if you do a freebsd-update upgrade, you can upgrade. > > > > Is that suppose to happen? > > > > That does not say that the freebsd-update bits will not change *until* > the official release announcement has been sent. > > In my past 15 years involved in the Project, I think we have been very > clear on that. > > A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT. > > I mean, c'mon, dude. > > We really, seriously, for all intents and purposes, cannot be any more > clear than that. > > So, yes, *IF* an update necessitates a new freebsd-update build, what > you are running is *NOT* official. > > For at least 15 years, we have all said the same entire thing. > >>> > >>> Yes, but, if at this point we had to rebuild, it would have to be 14.0.1 > >>> or something (which we have done a few times in the past). It would be > >>> too confusing otherwise once the bits are built and published (where > >>> published means "uploaded to our CDN"). It is the 14.0 release bits, > >>> the only question is if for some reason we had a dire emergency that > >>> meant we had to pull it at the last minute and publish different bits > >>> (under a different release name). > >>> > >>> Realistically, once the bits are available, we can't prevent people from > >>> using them, it's just at their own risk to do so until the project says > >>> "yes, we believe these are good". Granted, they are under the same risk > >>> if they are still running the last RC. The best way to minimize that > >>> risk going forward is to add more automation of testing/CI to go along > >>> with the process of building release bits so that the build artifacts > >>> from the release build run through CI and are only published if the CI > >>> is green as that would give us greater confidence of "we believe these > >>> are good" before they are uploaded for publishing. > >>> > >> > >> You are correct on all points. If there were a need to re-roll 14.0, it > >> would indeed necessitate a release/14.0.1 tag. Note, release/14.0.0 has > >> not yet been tagged, and I find it extremely unlikely that it will be > >> necessary to rebuild from a release/14.0.1 tag. > >> > >> 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. > >> > >> My email was intended to be informative. Period. > >> > >> There were no suggestions that 14.0-RELEASE was not yet final. And to > >> be fair, I had to personally deal with the fallout of a release "too > >> soon", notably 11.0-RELEASE, where I thought a critical issue had been > >> addressed, but I was wrong. > >> > >> My only point, in being overly open to the public on the delay, is that > >> we (the Release Engineering Team) are not yet ready to rubber-stamp this > >> as complete, as there are some outstanding items that are pending that > >> have not yet completed. > >> > >> 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 an official announcement, or for being "not open enough" when > >> there is silence from RE when a release does not meet its scheduled > >>
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 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 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-RELEASE will be ready. It should only be another day or so before these things complete. Thank you for your understanding. >>> >>> I always just installed my copy. >>> >> >> 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. >> > > Howver if you do a freebsd-update upgrade, you can upgrade. > > Is that suppose to happen? > That does not say that the freebsd-update bits will not change *until* the official release announcement has been sent. In my past 15 years involved in the Project, I think we have been very clear on that. A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT. I mean, c'mon, dude. We really, seriously, for all intents and purposes, cannot be any more clear than that. So, yes, *IF* an update necessitates a new freebsd-update build, what you are running is *NOT* official. For at least 15 years, we have all said the same entire thing. >>> >>> Yes, but, if at this point we had to rebuild, it would have to be 14.0.1 >>> or something (which we have done a few times in the past). It would be >>> too confusing otherwise once the bits are built and published (where >>> published means "uploaded to our CDN"). It is the 14.0 release bits, >>> the only question is if for some reason we had a dire emergency that >>> meant we had to pull it at the last minute and publish different bits >>> (under a different release name). >>> >>> Realistically, once the bits are available, we can't prevent people from >>> using them, it's just at their own risk to do so until the project says >>> "yes, we believe these are good". Granted, they are under the same risk >>> if they are still running the last RC. The best way to minimize that >>> risk going forward is to add more automation of testing/CI to go along >>> with the process of building release bits so that the build artifacts >>> from the release build run through CI and are only published if the CI >>> is green as that would give us greater confidence of "we believe these >>> are good" before they are uploaded for publishing. >>> >> >> You are correct on all points. If there were a need to re-roll 14.0, it >> would indeed necessitate a release/14.0.1 tag. Note, release/14.0.0 has >> not yet been tagged, and I find it extremely unlikely that it will be >> necessary to rebuild from a release/14.0.1 tag. >> >> 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. >> >> My email was intended to be informative. Period. >> >> There were no suggestions that 14.0-RELEASE was not yet final. And to >> be fair, I had to personally deal with the fallout of a release "too >> soon", notably 11.0-RELEASE, where I thought a critical issue had been >> addressed, but I was wrong. >> >> My only point, in being overly open to the public on the delay, is that >> we (the Release Engineering Team) are not yet ready to rubber-stamp this >> as complete, as there are some outstanding items that are pending that >> have not yet completed. >> >> 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 an official announcement, or for being "not open enough" when >> there is silence from RE when a release does not meet its scheduled >> announcement date. >> >> Glen >> >> > > What ahappened was that I inititated the freebsd-upgrade RELEASE upgrade > command. > > question should that RELEASe been released? > > -- > Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca > Yahweh, King & country!Never
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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, 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 an official announcement, or for being "not open enough" when >>> there is silence from RE when a release does not meet its scheduled >>> announcement date. >> Glen I appreciate your transparency and the efforts you have done to keep >> everyone in the loop. I think people get excited about new releases, which >> is probably a good thing. IMHO i feel you've been striking a good balance. >> As an operator these updates are really helpful for me as it allows me to >> adjust timelines on my end for updating my fleet of servers. You and the RE >> team do an incredible job - and personally I am thankful for the caution and >> common sense you all bring to this complex process. >> Cheers, >> -pete >> -- >> Pete Wright >> p...@nomadlogic.org >> @nomadlogicLA > +1 from a retired RE manager > yet another hard thankless job in the development chain... > > -- > When you beleve in things. that you don't understand, > then you suffer, superstition ain't the way. > Stevie Wonder - 1972 >
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 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-RELEASE will be ready. > > > > > > > > > > > > > > It should only be another day or so before these things complete. > > > > > > > > > > > > > > Thank you for your understanding. > > > > > > > > > > > > > > > > > > > I always just installed my copy. > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > Howver if you do a freebsd-update upgrade, you can upgrade. > > > > > > > > Is that suppose to happen? > > > > > > > > > > That does not say that the freebsd-update bits will not change *until* > > > the official release announcement has been sent. > > > > > > In my past 15 years involved in the Project, I think we have been very > > > clear on that. > > > > > > A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT. > > > > > > I mean, c'mon, dude. > > > > > > We really, seriously, for all intents and purposes, cannot be any more > > > clear than that. > > > > > > So, yes, *IF* an update necessitates a new freebsd-update build, what > > > you are running is *NOT* official. > > > > > > For at least 15 years, we have all said the same entire thing. > > > > Yes, but, if at this point we had to rebuild, it would have to be 14.0.1 > > or something (which we have done a few times in the past). It would be > > too confusing otherwise once the bits are built and published (where > > published means "uploaded to our CDN"). It is the 14.0 release bits, > > the only question is if for some reason we had a dire emergency that > > meant we had to pull it at the last minute and publish different bits > > (under a different release name). > > > > Realistically, once the bits are available, we can't prevent people from > > using them, it's just at their own risk to do so until the project says > > "yes, we believe these are good". Granted, they are under the same risk > > if they are still running the last RC. The best way to minimize that > > risk going forward is to add more automation of testing/CI to go along > > with the process of building release bits so that the build artifacts > > from the release build run through CI and are only published if the CI > > is green as that would give us greater confidence of "we believe these > > are good" before they are uploaded for publishing. > > > > You are correct on all points. If there were a need to re-roll 14.0, it > would indeed necessitate a release/14.0.1 tag. Note, release/14.0.0 has > not yet been tagged, and I find it extremely unlikely that it will be > necessary to rebuild from a release/14.0.1 tag. > > 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. > > My email was intended to be informative. Period. > > There were no suggestions that 14.0-RELEASE was not yet final. And to > be fair, I had to personally deal with the fallout of a release "too > soon", notably 11.0-RELEASE, where I thought a critical issue had been > addressed, but I was wrong. > > My only point, in being overly open to the public on the delay, is that > we (the Release Engineering Team) are not yet ready to rubber-stamp this > as complete, as there are some outstanding items that are pending that > have not yet completed. > > 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 an official announcement, or for being "not open enough" when > there is silence from RE when a release does not meet its scheduled > announcement date. > > Glen > > What ahappened was that I inititated the freebsd-upgrade RELEASE upgrade command. question should that RELEASe been released? -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen Lest we forget 11 Nov 2023 Beware https://mindspring.com
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 above > > context. We either get chastised for being "too open" into insights > > delaying an official announcement, or for being "not open enough" when > > there is silence from RE when a release does not meet its scheduled > > announcement date. > Glen I appreciate your transparency and the efforts you have done to keep > everyone in the loop. I think people get excited about new releases, which is > probably a good thing. IMHO i feel you've been striking a good balance. > > As an operator these updates are really helpful for me as it allows me to > adjust timelines on my end for updating my fleet of servers. You and the RE > team do an incredible job - and personally I am thankful for the caution and > common sense you all bring to this complex process. > Thank you very much, Pete, for your email on this. It is appreciated by all of us involved in FreeBSD releases. Best regards, Glen signature.asc Description: PGP signature
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 an official announcement, or for being "not open enough" when there is silence from RE when a release does not meet its scheduled announcement date. Glen I appreciate your transparency and the efforts you have done to keep everyone in the loop. I think people get excited about new releases, which is probably a good thing. IMHO i feel you've been striking a good balance. As an operator these updates are really helpful for me as it allows me to adjust timelines on my end for updating my fleet of servers. You and the RE team do an incredible job - and personally I am thankful for the caution and common sense you all bring to this complex process. Cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 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 before these things complete. > > > > > > > > > > > > Thank you for your understanding. > > > > > > > > > > > > > > > > I always just installed my copy. > > > > > > > > > > > > > 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. > > > > > > > > > > Howver if you do a freebsd-update upgrade, you can upgrade. > > > > > > Is that suppose to happen? > > > > > > > That does not say that the freebsd-update bits will not change *until* > > the official release announcement has been sent. > > > > In my past 15 years involved in the Project, I think we have been very > > clear on that. > > > > A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT. > > > > I mean, c'mon, dude. > > > > We really, seriously, for all intents and purposes, cannot be any more > > clear than that. > > > > So, yes, *IF* an update necessitates a new freebsd-update build, what > > you are running is *NOT* official. > > > > For at least 15 years, we have all said the same entire thing. > > Yes, but, if at this point we had to rebuild, it would have to be 14.0.1 > or something (which we have done a few times in the past). It would be > too confusing otherwise once the bits are built and published (where > published means "uploaded to our CDN"). It is the 14.0 release bits, > the only question is if for some reason we had a dire emergency that > meant we had to pull it at the last minute and publish different bits > (under a different release name). > > Realistically, once the bits are available, we can't prevent people from > using them, it's just at their own risk to do so until the project says > "yes, we believe these are good". Granted, they are under the same risk > if they are still running the last RC. The best way to minimize that > risk going forward is to add more automation of testing/CI to go along > with the process of building release bits so that the build artifacts > from the release build run through CI and are only published if the CI > is green as that would give us greater confidence of "we believe these > are good" before they are uploaded for publishing. > You are correct on all points. If there were a need to re-roll 14.0, it would indeed necessitate a release/14.0.1 tag. Note, release/14.0.0 has not yet been tagged, and I find it extremely unlikely that it will be necessary to rebuild from a release/14.0.1 tag. 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. My email was intended to be informative. Period. There were no suggestions that 14.0-RELEASE was not yet final. And to be fair, I had to personally deal with the fallout of a release "too soon", notably 11.0-RELEASE, where I thought a critical issue had been addressed, but I was wrong. My only point, in being overly open to the public on the delay, is that we (the Release Engineering Team) are not yet ready to rubber-stamp this as complete, as there are some outstanding items that are pending that have not yet completed. 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 an official announcement, or for being "not open enough" when there is silence from RE when a release does not meet its scheduled announcement date. Glen signature.asc Description: PGP signature
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 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 always just installed my copy. 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. Howver if you do a freebsd-update upgrade, you can upgrade. Is that suppose to happen? That does not say that the freebsd-update bits will not change *until* the official release announcement has been sent. In my past 15 years involved in the Project, I think we have been very clear on that. A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT. I mean, c'mon, dude. We really, seriously, for all intents and purposes, cannot be any more clear than that. So, yes, *IF* an update necessitates a new freebsd-update build, what you are running is *NOT* official. For at least 15 years, we have all said the same entire thing. Yes, but, if at this point we had to rebuild, it would have to be 14.0.1 or something (which we have done a few times in the past). It would be too confusing otherwise once the bits are built and published (where published means "uploaded to our CDN"). It is the 14.0 release bits, the only question is if for some reason we had a dire emergency that meant we had to pull it at the last minute and publish different bits (under a different release name). Realistically, once the bits are available, we can't prevent people from using them, it's just at their own risk to do so until the project says "yes, we believe these are good". Granted, they are under the same risk if they are still running the last RC. The best way to minimize that risk going forward is to add more automation of testing/CI to go along with the process of building release bits so that the build artifacts from the release build run through CI and are only published if the CI is green as that would give us greater confidence of "we believe these are good" before they are uploaded for publishing. -- John Baldwin
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 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. > >> That does not say that the freebsd-update bits will not change *until* >> the official release announcement has been sent. >> >> In my past 15 years involved in the Project, I think we have been very >> clear on that. >> >> A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT. >> >> I mean, c'mon, dude. >> >> We really, seriously, for all intents and purposes, cannot be any more >> clear than that. >> >> So, yes, *IF* an update necessitates a new freebsd-update build, what >> you are running is *NOT* official. >> >> For at least 15 years, we have all said the same entire thing. > > Here I have been tracking 14.0 release candidates > > Reminds me of when slashdot would announce a new release days before it > was actually released and then someone would remind them of that > > I am using an Australian mirror so will probably need to wait an extra > day to be on the safe side :-) > > > >
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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. > > > > That does not say that the freebsd-update bits will not change *until* > the official release announcement has been sent. > > In my past 15 years involved in the Project, I think we have been very > clear on that. > > A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT. > > I mean, c'mon, dude. > > We really, seriously, for all intents and purposes, cannot be any more > clear than that. > > So, yes, *IF* an update necessitates a new freebsd-update build, what > you are running is *NOT* official. > > For at least 15 years, we have all said the same entire thing. Here I have been tracking 14.0 release candidates Reminds me of when slashdot would announce a new release days before it was actually released and then someone would remind them of that I am using an Australian mirror so will probably need to wait an extra day to be on the safe side :-)
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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-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 always just installed my copy. > > > > > > > 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. > > > > Howver if you do a freebsd-update upgrade, you can upgrade. > > Is that suppose to happen? > That does not say that the freebsd-update bits will not change *until* the official release announcement has been sent. In my past 15 years involved in the Project, I think we have been very clear on that. A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT. I mean, c'mon, dude. We really, seriously, for all intents and purposes, cannot be any more clear than that. So, yes, *IF* an update necessitates a new freebsd-update build, what you are running is *NOT* official. For at least 15 years, we have all said the same entire thing. Glen signature.asc Description: PGP signature
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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-RELEASE will be ready. > > > > > > It should only be another day or so before these things complete. > > > > > > Thank you for your understanding. > > > > > > > I always just installed my copy. > > > > 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. > Howver if you do a freebsd-update upgrade, you can upgrade. Is that suppose to happen? > Glen > -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen Lest we forget 11 Nov 2023 Beware https://mindspring.com
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 before these things complete. > > > > Thank you for your understanding. > > > > I always just installed my copy. > 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. Glen signature.asc Description: PGP signature
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 always just installed my copy. > Glen > On behalf of: re@ > -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen Lest we forget 11 Nov 2023 Beware https://mindspring.com
Re: Heads up: s/u_intXX_t/uintXX_t/ in sys/cam
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. And many of these drivers are vendor code, to various degrees. I think this is the ideal time: Before the 14 branch, when all I need to do is merge to 13 since 12 is about to go out of support. There will never be a better time. Please let me know if I missed anything. or there are problems. Warner On Fri, Jul 7, 2023 at 3:12 PM Warner Losh wrote: > I plan on finally biting the bullet and moving to the standard uintXX_t. > > I plan on doing this next week, before we branch 14. > > I also plan on MFC'ing these changes (or rather running the same script > and tagging that commit as a MFC). > > This has been talked about forever, and now seems like we have a good lull > in things to do it. > > Comments? > > Warner > >
Re: HEADS-UP: PIE enabled by default on stable/13
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@ > >>> > >>> 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 when booting the kernel. > > If you track stable/13 and normally build WITHOUT_CLEAN you'll need to > do one initial clean build -- either run `make cleanworld` or set > WITH_CLEAN=yes. > > The change is a pure MFC of the changes integrated to -CURRENT early > 2021 and no issues are expected, but in case any problems are observed, > please issue a PR and/or let me know in this thread. > > Best regards, > Marcin > >>> > >> > >> Thanks for enabling this. If I understand it correctly we got some > >> improvements mentioned here[1] and it doesn't imply that ASLR has to be > >> enabled, especially kern.elf64.aslr.pie_enable can be still set to 0 ? > >> > > > > Currently it still remains opt-in on stable/13 and is disabled by default. > > > > Best regards, > > Marcin > > Thanks for the answer. I am not willing to turn ASLR on at this point, > but rather asking if my world, already built with PIE, will bring any > other enhancements or improvements? > If your world is already built with PIE, the MFC'ed patches should make no difference at all. Best regards, Marcin > > > >> > >> [1] https://www.mail-archive.com/freebsd-current@freebsd.org/msg183605.html > >> > > > With kind regards, > > -- > Marek Zarychta
Re: HEADS-UP: PIE enabled by default on stable/13
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 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 need to do one initial clean build -- either run `make cleanworld` or set WITH_CLEAN=yes. The change is a pure MFC of the changes integrated to -CURRENT early 2021 and no issues are expected, but in case any problems are observed, please issue a PR and/or let me know in this thread. Best regards, Marcin Thanks for enabling this. If I understand it correctly we got some improvements mentioned here[1] and it doesn't imply that ASLR has to be enabled, especially kern.elf64.aslr.pie_enable can be still set to 0 ? Currently it still remains opt-in on stable/13 and is disabled by default. Best regards, Marcin Thanks for the answer. I am not willing to turn ASLR on at this point, but rather asking if my world, already built with PIE, will bring any other enhancements or improvements? [1] https://www.mail-archive.com/freebsd-current@freebsd.org/msg183605.html With kind regards, -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: HEADS-UP: PIE enabled by default on stable/13
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 > >> 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 need to do > >> one initial clean build -- either run `make cleanworld` or set > >> WITH_CLEAN=yes. > >> > >> The change is a pure MFC of the changes integrated to -CURRENT early 2021 > >> and no issues are expected, but in case any problems are observed, please > >> issue a PR and/or let me know in this thread. > >> > >> Best regards, > >> Marcin > > > > Thanks for enabling this. If I understand it correctly we got some > improvements mentioned here[1] and it doesn't imply that ASLR has to be > enabled, especially kern.elf64.aslr.pie_enable can be still set to 0 ? > Currently it still remains opt-in on stable/13 and is disabled by default. Best regards, Marcin > > [1] https://www.mail-archive.com/freebsd-current@freebsd.org/msg183605.html >
Re: HEADS-UP: PIE enabled by default on stable/13
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 can be done simply by sysctls knobs when booting the kernel. If you track stable/13 and normally build WITHOUT_CLEAN you'll need to do one initial clean build -- either run `make cleanworld` or set WITH_CLEAN=yes. The change is a pure MFC of the changes integrated to -CURRENT early 2021 and no issues are expected, but in case any problems are observed, please issue a PR and/or let me know in this thread. Best regards, Marcin Thanks for enabling this. If I understand it correctly we got some improvements mentioned here[1] and it doesn't imply that ASLR has to be enabled, especially kern.elf64.aslr.pie_enable can be still set to 0 ? [1] https://www.mail-archive.com/freebsd-current@freebsd.org/msg183605.html -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: HEADS-UP: PIE enabled by default on stable/13
+ 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 simply > by sysctls knobs when booting the kernel. > > If you track stable/13 and normally build WITHOUT_CLEAN you'll need to do one > initial clean build -- either run `make cleanworld` or set WITH_CLEAN=yes. > > The change is a pure MFC of the changes integrated to -CURRENT early 2021 and > no issues are expected, but in case any problems are observed, please issue a > PR and/or let me know in this thread. > > Best regards, > Marcin
Re: HEADS-UP: PIE enabled by default on stable/13
+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 when booting the kernel. > > If you track stable/13 and normally build WITHOUT_CLEAN you'll need to do one > initial clean build -- either run `make cleanworld` or set WITH_CLEAN=yes. > > The change is a pure MFC of the changes integrated to -CURRENT early 2021 and > no issues are expected, but in case any problems are observed, please issue a > PR and/or let me know in this thread. > > Best regards, > Marcin
Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main
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 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 crashing with a seg fault and the > > core dump is no help to me at all: > > [freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo gdb > > ../../bin/sdcc sdcc.core > > GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] > > > > Reading symbols from ../../bin/sdcc... > > [New LWP 100122] > > Core was generated by `../../bin/sdcc -I../../device/include > > -I../../device/include/mcs51 -mds390 --nos'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > Invalid permissions for mapped object. > > #0 0x000804e3fbc0 in setrlimit () from /lib/libc.so.7 > > (gdb) info thread > > Id Target Id Frame > > * 1LWP 1001220x000804e3fbc0 in setrlimit () from > > /lib/libc.so.7 > > (gdb) bt > > #0 0x000804e3fbc0 in setrlimit () from /lib/libc.so.7 > > Backtrace stopped: Cannot access memory at address 0x7f87fd08 > > > > If I disable ASLR (via proccontrol) then it does not crash, but I am not > > sure how I can debug it further. > > > > I've raised a bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303 > > if you (or anyone else) has suggestions for what to try. > > > > Thanks for filing the ticket. Let's continue the conversation there. I left a comment there. The gist of it is that there are several lingering problems with the stack gap implementation, and I think we should re-disable it on main until there's some consensus on how to proceed.
Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main
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 efforts here, it is appreciated :) > > I am finding that the lang/sdcc port is crashing with a seg fault and the > core dump is no help to me at all: > [freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo gdb > ../../bin/sdcc sdcc.core > GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] > > Reading symbols from ../../bin/sdcc... > [New LWP 100122] > Core was generated by `../../bin/sdcc -I../../device/include > -I../../device/include/mcs51 -mds390 --nos'. > Program terminated with signal SIGSEGV, Segmentation fault. > Invalid permissions for mapped object. > #0 0x000804e3fbc0 in setrlimit () from /lib/libc.so.7 > (gdb) info thread > Id Target Id Frame > * 1LWP 1001220x000804e3fbc0 in setrlimit () from > /lib/libc.so.7 > (gdb) bt > #0 0x000804e3fbc0 in setrlimit () from /lib/libc.so.7 > Backtrace stopped: Cannot access memory at address 0x7f87fd08 > > If I disable ASLR (via proccontrol) then it does not crash, but I am not sure > how I can debug it further. > > I've raised a bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303 if > you (or anyone else) has suggestions for what to try. > Thanks for filing the ticket. Let's continue the conversation there. Best regards, Marcin
Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main
> 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 crashing with a seg fault and the core dump is no help to me at all: [freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo gdb ../../bin/sdcc sdcc.core GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] Reading symbols from ../../bin/sdcc... [New LWP 100122] Core was generated by `../../bin/sdcc -I../../device/include -I../../device/include/mcs51 -mds390 --nos'. Program terminated with signal SIGSEGV, Segmentation fault. Invalid permissions for mapped object. #0 0x000804e3fbc0 in setrlimit () from /lib/libc.so.7 (gdb) info thread Id Target Id Frame * 1LWP 1001220x000804e3fbc0 in setrlimit () from /lib/libc.so.7 (gdb) bt #0 0x000804e3fbc0 in setrlimit () from /lib/libc.so.7 Backtrace stopped: Cannot access memory at address 0x7f87fd08 If I disable ASLR (via proccontrol) then it does not crash, but I am not sure how I can debug it further. I've raised a bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303 if you (or anyone else) has suggestions for what to try. Thanks. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum
Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main
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 036af1053acd6cae68c5fb6bed30508f2e40be13. The mkimg failures are indeed fixed by the above commit - it was just a latent bug in mkimg. I've opened PR 259968 as a tracking bug for outstanding issues found as a result of enabling ASLR by default, and submitted a PR for each of the three outstanding issues.
Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main
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.
Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main
> 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 by default.
>>>
>>> Address Space Layout Randomization (ASLR) is an exploit mitigation
>>> technique implemented in the majority of modern operating systems.
>>> It involves randomly positioning the base address of an executable
>>> and the position of libraries, heap, and stack, in a process's address
>>> space. Although over the years ASLR proved to not guarantee full OS
>>> security on its own, this mechanism can make exploitation more difficult
>>> (especially when combined with other methods, such as W^X).
>>>
>>> Tests on the tier 1 64-bit architectures demonstrated that the ASLR is
>>> stable and does not result in noticeable performance degradation,
>>> therefore it is considered safe to enable this mechanism by default.
>>> Moreover its effectiveness is increased for PIE (Position Independent
>>> Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE by
>>> default on 64-bit architectures"), building from src is not necessary
>>> to have PIE binaries and it is enough to control usage of ASLR in the
>>> OS solely by setting the appropriate sysctls. The defaults were toggled
>>> for the 64-bit PIE and non-PIE executables.
>>>
>>> As for the drawbacks, a consequence of using the ASLR is more
>>> significant VM fragmentation, hence the issues may be encountered
>>> in the systems with a limited address space in high memory consumption
>>> cases, such as buildworld. As a result, although the tests on 32-bit
>>> architectures with ASLR enabled were mostly on par with what was
>>> observed on 64-bit ones, the defaults for the former are not changed
>>> at this time. Also, for the sake of safety the feature remains disabled
>>> for 32-bit executables on 64-bit machines, too.
>>>
>>> The committed change affects the overall OS operation, so the
>>> following should be taken into consideration:
>>> * Address space fragmentation.
>>> * A changed ABI due to modified layout of address space.
>>> * More complicated debugging due to:
>>> * Non-reproducible address space layout between runs.
>>> * Some debuggers automatically disable ASLR for spawned processes,
>>>making target's environment different between debug and
>>>non-debug runs.
>>>
>>> The known issues (such as PR239873 or PR253208) have been fixed in
>>> HEAD up front, however please pay attention to the system behavior after
>>> upgrading the kernel to the newest revisions.
>>> In order to confirm/rule-out the dependency of any encountered issue
>>> on ASLR it is strongly advised to re-run the test with the feature
>>> disabled - it can be done by setting the following sysctls
>>> in the /etc/sysctl.conf file:
>>> kern.elf64.aslr.enable=0
>>> kern.elf64.aslr.pie_enable=0
>>>
>>> The change is a result of combined efforts under the auspices
>>> of the FreeBSD Foundation and the Semihalf team sponsored
>>> by Stormshield.
>>>
>>> Best regards,
>>> Marcin
>>
>> Thanks very much for working on this. FYI, there are some test cases
>> seem to be affected by this:
>>
>> https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19828/testReport/
>>
>> 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..
>>
>> I'm still checking them, but hope more people can join and fix them.
>>
>
> Thanks for bringing this up! Apart from
> sys.netpfil.common.dummynet.pf_nat other are 23 are new.
I’ve just managed to reproduce that one locally (it only happens if ipfw is
also loaded) and will dig in soon. It’s not going to be aslr related. You can
ignore that failure.
Kristof
Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main
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 Randomization (ASLR) is an exploit mitigation
> > technique implemented in the majority of modern operating systems.
> > It involves randomly positioning the base address of an executable
> > and the position of libraries, heap, and stack, in a process's address
> > space. Although over the years ASLR proved to not guarantee full OS
> > security on its own, this mechanism can make exploitation more difficult
> > (especially when combined with other methods, such as W^X).
> >
> > Tests on the tier 1 64-bit architectures demonstrated that the ASLR is
> > stable and does not result in noticeable performance degradation,
> > therefore it is considered safe to enable this mechanism by default.
> > Moreover its effectiveness is increased for PIE (Position Independent
> > Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE by
> > default on 64-bit architectures"), building from src is not necessary
> > to have PIE binaries and it is enough to control usage of ASLR in the
> > OS solely by setting the appropriate sysctls. The defaults were toggled
> > for the 64-bit PIE and non-PIE executables.
> >
> > As for the drawbacks, a consequence of using the ASLR is more
> > significant VM fragmentation, hence the issues may be encountered
> > in the systems with a limited address space in high memory consumption
> > cases, such as buildworld. As a result, although the tests on 32-bit
> > architectures with ASLR enabled were mostly on par with what was
> > observed on 64-bit ones, the defaults for the former are not changed
> > at this time. Also, for the sake of safety the feature remains disabled
> > for 32-bit executables on 64-bit machines, too.
> >
> > The committed change affects the overall OS operation, so the
> > following should be taken into consideration:
> > * Address space fragmentation.
> > * A changed ABI due to modified layout of address space.
> > * More complicated debugging due to:
> > * Non-reproducible address space layout between runs.
> > * Some debuggers automatically disable ASLR for spawned processes,
> > making target's environment different between debug and
> > non-debug runs.
> >
> > The known issues (such as PR239873 or PR253208) have been fixed in
> > HEAD up front, however please pay attention to the system behavior after
> > upgrading the kernel to the newest revisions.
> > In order to confirm/rule-out the dependency of any encountered issue
> > on ASLR it is strongly advised to re-run the test with the feature
> > disabled - it can be done by setting the following sysctls
> > in the /etc/sysctl.conf file:
> > kern.elf64.aslr.enable=0
> > kern.elf64.aslr.pie_enable=0
> >
> > The change is a result of combined efforts under the auspices
> > of the FreeBSD Foundation and the Semihalf team sponsored
> > by Stormshield.
> >
> > Best regards,
> > Marcin
>
> Thanks very much for working on this. FYI, there are some test cases
> seem to be affected by this:
>
> https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19828/testReport/
>
> 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..
>
> I'm still checking them, but hope more people can join and fix them.
>
Thanks for bringing this up! Apart from
sys.netpfil.common.dummynet.pf_nat other are 23 are new. I checked a
couple of next builds and the results seems to be consistent. There
are:
lib.libc.sys.setrlimit_test.setrlimit_stack
lib.libc.regex.exhaust_test.regcomp_too_big
sys.kern.coredump_phnum_test.coredump_phnum
and 20 of usr.bin.mkimg.*
We will also check and try to fix the new issues (however any help
would be appreciated), it may be also worth to create dedicated
tickets in bugzilla.
Best regards,
Marcin
Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main
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 majority of modern operating systems.
> It involves randomly positioning the base address of an executable
> and the position of libraries, heap, and stack, in a process's address
> space. Although over the years ASLR proved to not guarantee full OS
> security on its own, this mechanism can make exploitation more difficult
> (especially when combined with other methods, such as W^X).
>
> Tests on the tier 1 64-bit architectures demonstrated that the ASLR is
> stable and does not result in noticeable performance degradation,
> therefore it is considered safe to enable this mechanism by default.
> Moreover its effectiveness is increased for PIE (Position Independent
> Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE by
> default on 64-bit architectures"), building from src is not necessary
> to have PIE binaries and it is enough to control usage of ASLR in the
> OS solely by setting the appropriate sysctls. The defaults were toggled
> for the 64-bit PIE and non-PIE executables.
>
> As for the drawbacks, a consequence of using the ASLR is more
> significant VM fragmentation, hence the issues may be encountered
> in the systems with a limited address space in high memory consumption
> cases, such as buildworld. As a result, although the tests on 32-bit
> architectures with ASLR enabled were mostly on par with what was
> observed on 64-bit ones, the defaults for the former are not changed
> at this time. Also, for the sake of safety the feature remains disabled
> for 32-bit executables on 64-bit machines, too.
>
> The committed change affects the overall OS operation, so the
> following should be taken into consideration:
> * Address space fragmentation.
> * A changed ABI due to modified layout of address space.
> * More complicated debugging due to:
> * Non-reproducible address space layout between runs.
> * Some debuggers automatically disable ASLR for spawned processes,
> making target's environment different between debug and
> non-debug runs.
>
> The known issues (such as PR239873 or PR253208) have been fixed in
> HEAD up front, however please pay attention to the system behavior after
> upgrading the kernel to the newest revisions.
> In order to confirm/rule-out the dependency of any encountered issue
> on ASLR it is strongly advised to re-run the test with the feature
> disabled - it can be done by setting the following sysctls
> in the /etc/sysctl.conf file:
> kern.elf64.aslr.enable=0
> kern.elf64.aslr.pie_enable=0
>
> The change is a result of combined efforts under the auspices
> of the FreeBSD Foundation and the Semihalf team sponsored
> by Stormshield.
>
> Best regards,
> Marcin
Thanks very much for working on this. FYI, there are some test cases
seem to be affected by this:
https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19828/testReport/
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..
I'm still checking them, but hope more people can join and fix them.
Best,
Li-Wen
Re: [HEADS UP] Rename of the vendor/openzfs branch
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 The renaming has been done: https://cgit.freebsd.org/src/log/?h=vendor/openzfs/legacy If you have a local branch tracking vendor/openzfs, please refer to the previous mail for migration. https://lists.freebsd.org/archives/freebsd-git/2021-June/15.html Best, Li-Wen
Re: HEADS-UP: PIE enabled by default on main
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. Like PIE, I trip across how to enable them after the fact by finding people talking about it here. My google-fu is getting a lot of bad hits, but I assume this is referring to making writable memory non-executable (above and beyond malloc()'s M_EXEC flag with it's disclaimers). What are the keyword/feature/knobs to get better informed and opt-in? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
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 sarcasm (or any other form of > "humor") or is a serious statement? But this does leave me with a whole > bunch of questions.. > > If this is really how Konstantin is describing it then is it OK to say > about this to the whole Internet? Why FreeBSD Foundation is paying for > meaningless work then? Why members of the Core team do this work? Does > this mean that FreeBSD is working to satisfy the silly needs of some fat > customer? What about project independence and not being controlled by > big money? What fat customer? Other than that (and tone, of course), you formulate right the core of the issue. ASLR is useless as a stop-gap measure, exploits work around it with full success since XP SP3, but the myth about its importance is so widely circulating that we have to spend a lot of efforts first developing the feature, and then similar amount of efforts to productize it. The later means to make it available to general public without introducing a breakage. We tried to do as you said, not implement but explain, you see the attempts to list research papers below the thread. It does not work. This is the case where security theater wins. In fact, switch to PIE itself is somewhat useful. For instance, - rtld direct execution mode benefits from it - kernel image activator might optimize/compact address space - emulation tools like valgrind have more freedom loading the image as well, - static linkers can do some optimizations only possible for DSO-like and not binary and so on. But I would never call it a 'huge security advance'. > > Where can I read about ASLR and security myths? > Why not spend time and explain why this does not work? Because spending time explaining why it does not work does not work. People read check-lists and not explanations, esp. if check-lists are provided by somebody not interested in explanation, but to pursue a red/green line in the check-list. And I do not even start on the quality of the 'alternative' implementations. > > > > You clearly should mean something useful and much more important than that, > > when stating that FreeBSD made a huge step forward. So I want to be aware > > of the advance. > > Why attack a person who was really happy for the project? > This DOES sound a agressive, even for a sarcastic joke.. > I am saying this someone who shares the same native language with Mr. > Belousov, > it is not a "language/culture" difference thing. I do not see how supposed sharing of native language with me makes it legitimate to express your emotions as mine statements. > > - > just your regular user who reads mailing list ocassionally > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
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 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 leave me with a whole > > bunch of questions.. > > > > If this is really how Konstantin is describing it then is it OK to say > > about this to the whole Internet? Why FreeBSD Foundation is paying for > > meaningless work then? Why members of the Core team do this work? Does > > this mean that FreeBSD is working to satisfy the silly needs of some fat > > customer? What about project independence and not being controlled by > > big money? > > > > Where can I read about ASLR and security myths? > > Why not spend time and explain why this does not work? > > > > Not to rise to the baitiness of all these leading questions (they really > are quite contrary to how our community usually comports itself, but for > the sake of civil discourse, I'll ignore) > > I'll bet it has something to do with the many known ASLR attacks. One is > chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which show > how MMU side channels can defeat ASLR. Or maybe he's familiar with the > offset2lib attack against Linux 64-bit ASLR documented in this paper > https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. > There's many others as well that show the shortcomings of ASLR and disclose > ways to defeat it using various clever means. Problem with these papers is that they put ASLR on a pedestal it doesn't deserve. If you take a look at PaX's original ASLR paper, you'll learn that ASLR was not designed to protect against local attacks. You'll also learn that the infoleak weakness was already postulated, even in its initial design and implementation. Attacks against the MMU require local code execution--for example, javascript in a browser. ASLR was never meant to protect against such a case. We must take the original design into account when discussing ASLR's valid shortcomings. 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. When combined with W^X, exploit authors must chain together multiple vulnerabilities in order to successfully exploit. The combination of ASLR and W^X have forever changed the very foundation of exploitation. Both, when combined, do their job well--that of raising the economic cost of successful remote exploitation. Now that FreeBSD has both a form of ASLR known as ASR and a W^X implementation, FreeBSD can move on to other exploit mitigations, such as CFI and SafeStack (both of which are already integrated in some form in HardenedBSD.) This is likely to be my only response to this thread as I'm incredibly tired of rehashing the same arguments, especiall with regards to kib@, over the span of many years. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: HEADS-UP: PIE enabled by default on main
> 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 or HardenedBSD (both use the strongest ASLR available > AFAIK). > > Saying that security mitigation features that affect no performance > are "meaningless", is just ridiculous or at least just irresponsible. > It's like telling C programmers that stack protection or out of bounds > checks are bad, cause there's nothing wrong with random SEGFAULTS from > time to time… > You seem to forget that those mechanisms are there exactly because programmers are not caring about random faults from time to time:D With correct code, one would not need mechanisms like ALSR. rgds, toomas > > On 28/02/2021, Ihor Antonov wrote: >> 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. 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 leave me with a whole bunch of questions.. If this is really how Konstantin is describing it then is it OK to say about this to the whole Internet? Why FreeBSD Foundation is paying for meaningless work then? Why members of the Core team do this work? Does this mean that FreeBSD is working to satisfy the silly needs of some fat customer? What about project independence and not being controlled by big money? Where can I read about ASLR and security myths? >>> >>> Why not spend time and explain why this does not work? >>> >>> Not to rise to the baitiness of all these leading questions (they really >>> are quite contrary to how our community usually comports itself, but for >>> the sake of civil discourse, I'll ignore) >>> >>> I'll bet it has something to do with the many known ASLR attacks. One is >>> chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which >>> show >>> how MMU side channels can defeat ASLR. Or maybe he's familiar with the >>> offset2lib attack against Linux 64-bit ASLR documented in this paper >>> https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. >>> There's many others as well that show the shortcomings of ASLR and >>> disclose >>> ways to defeat it using various clever means. >> >> Warner, thanks for the links. They are indeed interesting. >> You clearly should mean something useful and much more important than that, >>> >>> Maybe he'd like to understand how PIE accomplishes better security give >>> the >>> known ASLR weaknesses. And rather than take a sarcastic tone, he asked >>> for >>> more details that back up the earlier claims of improved security so we >>> could all learn something. >> >> The conclusion of the paper in the second link clearly says: >> >>We present a new weakness on the current implementationof the ASLR >>Linux systems which affects PIE compiled ex-ecutables. Applications >>compiled with PIE are consideredto be more robust since it makes >>attacks more difficult. >> >> Which I read as ASLR and PIE work better together. This is the same what >> Gordon was saying. >> >> The whole situation is wrong on 2 different levels. >> >> First: saying that ASLR is not perfect and can be broken is not the same >> thing as saying "The only purpose of it is to have a check-list item ticked >> green" >> >> There are no perfect security measures, and you guys (kernel and OS >> developers) should know that better than us (users). Hackers find new >> exploits, developers find ways to mitigate them and cycle repeats. Just >> the fact that ASLR can be broken is not the reason to not have it. >> >> Second: look at this exchange from a distance >> >> Ed: we are enabling security feature X, please rebuild your worlds.. >> Godron: great progress! go team! >> Konstantin: why do you think this is great progress? (implying it is >> not) >> Gordon: well, I heard feature X works best with feature Y >> Konstantin: feature Y is useless checkbox, next time you speak make sure >> you say something useful! >> >> Considering the fact that Konstantin himself worked on ASLR this is at >> least confusing.. Also does this also mean that feature X (PIE) is also >> useless checkbox? >> >> Konstantin, Ed, Warner - I dunno what is going on in your house (Core) but >> it does not look good form the outside. You are sending mixed signals to >> your auditory. >> >> >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
Re: HEADS-UP: PIE enabled by default on main
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). Saying that security mitigation features that affect no performance are "meaningless", is just ridiculous or at least just irresponsible. It's like telling C programmers that stack protection or out of bounds checks are bad, cause there's nothing wrong with random SEGFAULTS from time to time… On 28/02/2021, Ihor Antonov wrote: > 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. >> > >> > 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 leave me with a whole >> > bunch of questions.. >> > >> > If this is really how Konstantin is describing it then is it OK to say >> > about this to the whole Internet? Why FreeBSD Foundation is paying for >> > meaningless work then? Why members of the Core team do this work? Does >> > this mean that FreeBSD is working to satisfy the silly needs of some >> > fat >> > customer? What about project independence and not being controlled by >> > big money? >> > >> > Where can I read about ASLR and security myths? >> >> Why not spend time and explain why this does not work? >> > >> >> Not to rise to the baitiness of all these leading questions (they really >> are quite contrary to how our community usually comports itself, but for >> the sake of civil discourse, I'll ignore) >> >> I'll bet it has something to do with the many known ASLR attacks. One is >> chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which >> show >> how MMU side channels can defeat ASLR. Or maybe he's familiar with the >> offset2lib attack against Linux 64-bit ASLR documented in this paper >> https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. >> There's many others as well that show the shortcomings of ASLR and >> disclose >> ways to defeat it using various clever means. > > Warner, thanks for the links. They are indeed interesting. > >> > You clearly should mean something useful and much more important than >> > that, >> >> Maybe he'd like to understand how PIE accomplishes better security give >> the >> known ASLR weaknesses. And rather than take a sarcastic tone, he asked >> for >> more details that back up the earlier claims of improved security so we >> could all learn something. > > The conclusion of the paper in the second link clearly says: > > We present a new weakness on the current implementationof the ASLR > Linux systems which affects PIE compiled ex-ecutables. Applications > compiled with PIE are consideredto be more robust since it makes > attacks more difficult. > > Which I read as ASLR and PIE work better together. This is the same what > Gordon was saying. > > The whole situation is wrong on 2 different levels. > > First: saying that ASLR is not perfect and can be broken is not the same > thing as saying "The only purpose of it is to have a check-list item ticked > green" > > There are no perfect security measures, and you guys (kernel and OS > developers) should know that better than us (users). Hackers find new > exploits, developers find ways to mitigate them and cycle repeats. Just > the fact that ASLR can be broken is not the reason to not have it. > > Second: look at this exchange from a distance > > Ed: we are enabling security feature X, please rebuild your worlds.. > Godron: great progress! go team! > Konstantin: why do you think this is great progress? (implying it is > not) > Gordon: well, I heard feature X works best with feature Y > Konstantin: feature Y is useless checkbox, next time you speak make sure > you say something useful! > > Considering the fact that Konstantin himself worked on ASLR this is at > least confusing.. Also does this also mean that feature X (PIE) is also > useless checkbox? > > Konstantin, Ed, Warner - I dunno what is going on in your house (Core) but > it does not look good form the outside. You are sending mixed signals to > your auditory. > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- -- Daniel Dettlaff Versatile Knowledge Systems verknowsys.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
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. > > > > 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 leave me with a whole > > bunch of questions.. > > > > If this is really how Konstantin is describing it then is it OK to say > > about this to the whole Internet? Why FreeBSD Foundation is paying for > > meaningless work then? Why members of the Core team do this work? Does > > this mean that FreeBSD is working to satisfy the silly needs of some fat > > customer? What about project independence and not being controlled by > > big money? > > > > Where can I read about ASLR and security myths? > > Why not spend time and explain why this does not work? > > > > Not to rise to the baitiness of all these leading questions (they really > are quite contrary to how our community usually comports itself, but for > the sake of civil discourse, I'll ignore) > > I'll bet it has something to do with the many known ASLR attacks. One is > chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which show > how MMU side channels can defeat ASLR. Or maybe he's familiar with the > offset2lib attack against Linux 64-bit ASLR documented in this paper > https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. > There's many others as well that show the shortcomings of ASLR and disclose > ways to defeat it using various clever means. Warner, thanks for the links. They are indeed interesting. > > You clearly should mean something useful and much more important than > > that, > > Maybe he'd like to understand how PIE accomplishes better security give the > known ASLR weaknesses. And rather than take a sarcastic tone, he asked for > more details that back up the earlier claims of improved security so we > could all learn something. The conclusion of the paper in the second link clearly says: We present a new weakness on the current implementationof the ASLR Linux systems which affects PIE compiled ex-ecutables. Applications compiled with PIE are consideredto be more robust since it makes attacks more difficult. Which I read as ASLR and PIE work better together. This is the same what Gordon was saying. The whole situation is wrong on 2 different levels. First: saying that ASLR is not perfect and can be broken is not the same thing as saying "The only purpose of it is to have a check-list item ticked green" There are no perfect security measures, and you guys (kernel and OS developers) should know that better than us (users). Hackers find new exploits, developers find ways to mitigate them and cycle repeats. Just the fact that ASLR can be broken is not the reason to not have it. Second: look at this exchange from a distance Ed: we are enabling security feature X, please rebuild your worlds.. Godron: great progress! go team! Konstantin: why do you think this is great progress? (implying it is not) Gordon: well, I heard feature X works best with feature Y Konstantin: feature Y is useless checkbox, next time you speak make sure you say something useful! Considering the fact that Konstantin himself worked on ASLR this is at least confusing.. Also does this also mean that feature X (PIE) is also useless checkbox? Konstantin, Ed, Warner - I dunno what is going on in your house (Core) but it does not look good form the outside. You are sending mixed signals to your auditory. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
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 other form of > "humor") or is a serious statement? But this does leave me with a whole > bunch of questions.. > > If this is really how Konstantin is describing it then is it OK to say > about this to the whole Internet? Why FreeBSD Foundation is paying for > meaningless work then? Why members of the Core team do this work? Does > this mean that FreeBSD is working to satisfy the silly needs of some fat > customer? What about project independence and not being controlled by > big money? > > Where can I read about ASLR and security myths? Why not spend time and explain why this does not work? > Not to rise to the baitiness of all these leading questions (they really are quite contrary to how our community usually comports itself, but for the sake of civil discourse, I'll ignore) I'll bet it has something to do with the many known ASLR attacks. One is chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which show how MMU side channels can defeat ASLR. Or maybe he's familiar with the offset2lib attack against Linux 64-bit ASLR documented in this paper https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. There's many others as well that show the shortcomings of ASLR and disclose ways to defeat it using various clever means. > You clearly should mean something useful and much more important than > that, > > when stating that FreeBSD made a huge step forward. So I want to be > aware > > of the advance. > > Why attack a person who was really happy for the project? > This DOES sound a agressive, even for a sarcastic joke.. > I am saying this someone who shares the same native language with Mr. > Belousov, > it is not a "language/culture" difference thing. > just your regular user who reads mailing list ocassionally > Maybe he'd like to understand how PIE accomplishes better security give the known ASLR weaknesses. And rather than take a sarcastic tone, he asked for more details that back up the earlier claims of improved security so we could all learn something. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
> > 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 leave me with a whole bunch of questions.. If this is really how Konstantin is describing it then is it OK to say about this to the whole Internet? Why FreeBSD Foundation is paying for meaningless work then? Why members of the Core team do this work? Does this mean that FreeBSD is working to satisfy the silly needs of some fat customer? What about project independence and not being controlled by big money? Where can I read about ASLR and security myths? Why not spend time and explain why this does not work? > You clearly should mean something useful and much more important than that, > when stating that FreeBSD made a huge step forward. So I want to be aware > of the advance. Why attack a person who was really happy for the project? This DOES sound a agressive, even for a sarcastic joke.. I am saying this someone who shares the same native language with Mr. Belousov, it is not a "language/culture" difference thing. - just your regular user who reads mailing list ocassionally ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
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 (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 -CURRENT and normally build WITHOUT_CLEAN you'll need to > > > > do one initial clean build -- either run `make cleanworld` or set > > > > WITH_CLEAN=yes. > > > > > > > > No significant user-facing changes are expected from this change, but > > > > there are some minor ones. For example, `file` will indicate that > > > > binaries are PIE by reporting something like `ELF 64-bit LSB pie > > > > executable` rather than `ELF 64-bit LSB executable`. Also, for most > > > > workloads no notable performance impact is expected. > > > > > > > > For almost all ports this should result in no change. There are a > > > > small number of ports that use base system /usr/share/mk > > > > infrastructure and thus inherit the base system default, and some of > > > > those initially failed to build. Those found during an exp-run in > > > > PR253275 have been addressed or have patches waiting. > > > > > > > > Please watch out for any new issues after you next update the base > > > > system and/or ports, and report issues via a Bugzilla PR or in reply > > > > here. > > > > > > Thats a huge step forward in terms on security. > > Can you explain why? > > > > Thanks. > > I can try. Enabling PIE for every 64bit architecture is in that matter a step > forward in security as it enables ASLR for further adoption. 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. You clearly should mean something useful and much more important than that, when stating that FreeBSD made a huge step forward. So I want to be aware of the advance. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
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-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 -CURRENT and normally build WITHOUT_CLEAN you'll need to > > > do one initial clean build -- either run `make cleanworld` or set > > > WITH_CLEAN=yes. > > > > > > No significant user-facing changes are expected from this change, but > > > there are some minor ones. For example, `file` will indicate that > > > binaries are PIE by reporting something like `ELF 64-bit LSB pie > > > executable` rather than `ELF 64-bit LSB executable`. Also, for most > > > workloads no notable performance impact is expected. > > > > > > For almost all ports this should result in no change. There are a > > > small number of ports that use base system /usr/share/mk > > > infrastructure and thus inherit the base system default, and some of > > > those initially failed to build. Those found during an exp-run in > > > PR253275 have been addressed or have patches waiting. > > > > > > Please watch out for any new issues after you next update the base > > > system and/or ports, and report issues via a Bugzilla PR or in reply > > > here. > > > > Thats a huge step forward in terms on security. > Can you explain why? > > Thanks. I can try. Enabling PIE for every 64bit architecture is in that matter a step forward in security as it enables ASLR for further adoption. Thank You, again. --Gordon > > Thanks for the efforts and anyone involved. signature.asc Description: PGP signature
Re: HEADS-UP: PIE enabled by default on main
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 executables are used in conjunction with address > > randomization as a mitigation for certain types of security > > vulnerabilities. > > > > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to > > do one initial clean build -- either run `make cleanworld` or set > > WITH_CLEAN=yes. > > > > No significant user-facing changes are expected from this change, but > > there are some minor ones. For example, `file` will indicate that > > binaries are PIE by reporting something like `ELF 64-bit LSB pie > > executable` rather than `ELF 64-bit LSB executable`. Also, for most > > workloads no notable performance impact is expected. > > > > For almost all ports this should result in no change. There are a > > small number of ports that use base system /usr/share/mk > > infrastructure and thus inherit the base system default, and some of > > those initially failed to build. Those found during an exp-run in > > PR253275 have been addressed or have patches waiting. > > > > Please watch out for any new issues after you next update the base > > system and/or ports, and report issues via a Bugzilla PR or in reply > > here. > > Thats a huge step forward in terms on security. Can you explain why? Thanks. > Thanks for the efforts and anyone involved. > > --Gordon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
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 for certain types of security > vulnerabilities. > > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to > do one initial clean build -- either run `make cleanworld` or set > WITH_CLEAN=yes. > > No significant user-facing changes are expected from this change, but > there are some minor ones. For example, `file` will indicate that > binaries are PIE by reporting something like `ELF 64-bit LSB pie > executable` rather than `ELF 64-bit LSB executable`. Also, for most > workloads no notable performance impact is expected. > > For almost all ports this should result in no change. There are a > small number of ports that use base system /usr/share/mk > infrastructure and thus inherit the base system default, and some of > those initially failed to build. Those found during an exp-run in > PR253275 have been addressed or have patches waiting. > > Please watch out for any new issues after you next update the base > system and/or ports, and report issues via a Bugzilla PR or in reply > here. Thats a huge step forward in terms on security. Thanks for the efforts and anyone involved. --Gordon signature.asc Description: PGP signature
Re: HEADS-UP: PIE enabled by default on main
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 issue is that without a clean build you may have some .o files > left around that are built without PIE enabled (i.e., compiled without > -fPIE), and attempting to link them into a PIE executable will fail > with an error like: > > ld: error: can't create dynamic relocation R_X86_64_32 against local > symbol in readonly segment; recompile object files with -fPIC or pass > '-Wl,-z,notext' to allow text relocations in the output > FWIW, my source update from: FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1194 main-n245061-c861373bdff9: Thu Feb 25 04:09:17 PST 2021 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 145 145 to: FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1195 main-n245107-172f2fc11cc5: Fri Feb 26 04:01:22 PST 2021 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 145 145 this morning was quite uneventful. I did nothing special -- just the normal META_MODE build I always do. Rebooted; started X11 (built under stable/12, as with all of the ports save x11/nvidia-driver)... things Just Worked. :-) (Above was from one machine; I actually updated 3 machines in parallel.) Peace, david -- David H. Wolfskill da...@catwhisker.org It is supremely disingenuous to claim a lack of jurisdiction, then proceed to participate in a decision on the same matter. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: HEADS-UP: PIE enabled by default on main
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 without a clean build you may have some .o files > left around that are built without PIE enabled (i.e., compiled without > -fPIE), and attempting to link them into a PIE executable will fail Hmm, maybe it is time for a ".pieo" extension? (I disliked .pico at first, but now I see the sense in it; might as well make clear that plain ".o" is meant for 'static' object files.) -Dimitry signature.asc Description: Message signed with OpenPGP
Re: HEADS-UP: PIE enabled by default on main
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. > > The issue is that without a clean build you may have some .o files > left around that are built without PIE enabled (i.e., compiled without > -fPIE), and attempting to link them into a PIE executable will fail > with an error like: > > ld: error: can't create dynamic relocation R_X86_64_32 against local symbol > in readonly segment; recompile object files with -fPIC or pass > '-Wl,-z,notext' to allow text relocations in the output Ah, thanks. That makes more sense. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA signature.asc Description: PGP signature
Re: HEADS-UP: PIE enabled by default on main
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 around that are built without PIE enabled (i.e., compiled without -fPIE), and attempting to link them into a PIE executable will fail with an error like: ld: error: can't create dynamic relocation R_X86_64_32 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output I am not aware of any configuration that would link successfully, but then have some run-time failure. If it builds it should work. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
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 they introduce no additional constraints on running on older kernels. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
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. ... > > > > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to > > do one initial clean build -- either run `make cleanworld` or set > > WITH_CLEAN=yes. > > 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? Assuming we're basically talking about WITH_PIE=YES in /etc/src.conf, I've been doing this since 2020/08/04 (12.1 -> 12.2 -> 13/14). I don't think I've associated any problems with PIE. I've certainly got lots of non-PIE ports linked against base libraries (but ELF 64-bit LSB shared object, vs ELF 64-bit LSB pie executable). The E in PIE is executable. 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. I can't say that I've had an opportunity to try the scenario I think you're looking at. My "older" crossovers are +/- a __FreeBSD_version bump. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
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 mitigation for certain types of security > vulnerabilities. > > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to > do one initial clean build -- either run `make cleanworld` or set > WITH_CLEAN=yes. 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? Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA signature.asc Description: PGP signature
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 commit object. Yeah, the git commit object is essentially text with some headers, and the git tools are all permissive of unrecognized headers. You can create a "visually identical" commit (same commit message, parent commit(s), author/committer/dates, etc) by just adding an extra header with an arbitrary value and brute force on that value to find a vanity prefix. This isn't anything related to the SHA1 attacks, it's just brute-forcing the output of a truncated SHA1 to a 1-in-2^32 result. E.g., https://github.com/cemeyer/gitbrutec does it by injecting a header named "x-gitbrutec-nonce." $ git cat-file -p 009 tree 4e778673b8af45ecd4c62e8b1d1438d06db7f440 parent 0080b4fc4c2066fa05641e73d5f0985c15ea author Conrad Meyer 1590357489 -0700 committer Conrad Meyer 1590357489 -0700 x-gitbrutec-nonce YYZSKGIQCLLXGE Use 'git update-ref' in post-commit example ... > Now, > brute-forcing 8 digits in the hash is one thing and doing it for all > 40 is quite another, but I suspect that this demonstrates that it's > *possible* to do it for a git hash, given enough computing resources. SHA1 has always, by design, been vulnerable to a 2^80 resource attack :-). Best, Conrad ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 do not > offer extension-space for "attic-junk", are much harder to produce > *meaningful* collisions for. > > (I take no opinion in where git is on that spectrum.) 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 commit object. Now, brute-forcing 8 digits in the hash is one thing and doing it for all 40 is quite another, but I suspect that this demonstrates that it's *possible* to do it for a git hash, given enough computing resources. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 file as you need, without affecting the files normal function. Compact data formats, formats which leave no wiggle-room and do not offer extension-space for "attic-junk", are much harder to produce *meaningful* collisions for. (I take no opinion in where git is on that spectrum.) This is why I am very sceptical of the recent fashion of "GREASING" which the TLS WG have invented: To me that sounds like somebody is allocating wiggle-room for advanced cryptographic skullduggery. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 > matches a specific hash. What you can do is create a collision between > two blocks of data, varying both blocks in the process. This makes > SHA-1 unsuitable for digital signatures. TL;DR: No, SHA-1 is broken. PERIOD. 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. The paper released in 2019[2] and implemented in 2020 allows for chosen-prefix attacks[3] which means that SHA-1 is broken. It allows the creation of a different message prefix, but results in the same hash. Before this, git was "secure" in that objects were prepended w/ length and size, but w/ this latest attack, those can now be changed as well, allowing someone to wholesale replace a file in git w/ a different length, and the SHA-1 hash being the same. > A *third-party* attacker cannot create a bogus torrent using a > collision attack against SHA-1 because the attacker would need to match > a specific hash value. Wrong, see above. > What may be possible is that the creator of the legitimate torrent > might create two torrents with the same hash, but this seems very > contrived and not very useful. It has all sorts of problems as a way of > delivering targeted malware. Again, wrong. [1] https://en.wikipedia.org/wiki/SHA-1#SHAttered_%E2%80%93_first_public_collision [2] https://en.wikipedia.org/wiki/SHA-1#Birthday-Near-Collision_Attack_%E2%80%93_first_practical_chosen-prefix_attack [3] https://en.wikipedia.org/wiki/Collision_attack#Chosen-prefix_collision_attack -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
>> 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 examined for sensibility post. Even better before then, said fun audit teams raise the cost to compromising all N randomly changing slots on it, much harder to game than a single endpoint. Audit counters by a bit different path than the IT-people problems, does insert time in the process, yet can also payoff by quality, and by rotating participants gaining broader experience with entire codebase, and can even payout from said 10x crypto pot for bugs. Defense in depth, many knobs in the orchestra, turn to set how you want, yet consider before leaving any set too near zero. Good that git monotone hashtrees keys TLS sigs pubkey fingerprints pins TOTP automated lint coverage fuzzing zfs-skein, etc displacing equivalents of legacy telnet CVSROOT, in some OS and projects finally, and that development, being users too, have interest benefit in, and can contribute to that areas and transitions too. Happy hacking in 2021 :) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 going to *enforce* (how?!) that all committers only commit patches they received under full cryptographic & biometric custody from verified communications partners, it will always end up being unattributable. Even if you were able to pin the blame on a particular committer, that person would simply cease to exist, because it was only a cover identity to begin with. > > As interesting as this thread has been (not!) > > Contrare. > [...] > Defense in depth. ... is a lot harder than most IT-people realize, because most IT-people almost invariably ignore the entire human and political aspect of the problem. See also: "Operation Orchestra" by yours truly. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
> 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 thread's and other details, is how to attend that too. Luck playing guess the mole and trying to SF-86 and p2p everyone only goes so far. Stronger layered yet is a [change] audit group, selected randomly and randomly rotated through, all who must approve. And to provide alt eyes and counter self project bias, a review trade market with other OS projects denominated in LOC [fair weighted by spaghetti and doc ratios]. Pay for more coverage by foundation holding back 1/4 of its crypto donations and mining as investment. Defense in depth. Have fun. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 cryptography can or will protect against that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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. > > > > > > 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 > > > ed25519). I plan to do that sometime this coming week. I wonder if it > > > would be a good idea for FreeBSD to do the same > > > > The draft FreeBSD Git docs have the SSH fingerprints of the Git > > servers. > > https://github.com/bsdimp/freebsd-git-docs/blob/main/URLs.md > > > > Here's one from my own ~/.ssh/known_hosts: > > SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE git.freebsd.org (ED25519) > > And the ssh-keys file is available on the project site, signed with > security-officer's key: > > https://www.freebsd.org/internal/ssh-keys.asc > > And in that file's header: > """ > Note that all machines listed below also have signed SSHFP records in > DNS. If you have a DNSSEC-aware resolver and set VerifyHostKeyDNS to > "ask" or "yes" in ~/.ssh/config, OpenSSH will verify host keys against > these SSHFP records. > """ Awesome! Thanks for the clarification! Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 is > > publish on our site the ssh pubkeys of the server (both RSA and > > ed25519). I plan to do that sometime this coming week. I wonder if it > > would be a good idea for FreeBSD to do the same > > The draft FreeBSD Git docs have the SSH fingerprints of the Git > servers. > https://github.com/bsdimp/freebsd-git-docs/blob/main/URLs.md > > Here's one from my own ~/.ssh/known_hosts: > SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE git.freebsd.org (ED25519) And the ssh-keys file is available on the project site, signed with security-officer's key: https://www.freebsd.org/internal/ssh-keys.asc And in that file's header: """ Note that all machines listed below also have signed SSHFP records in DNS. If you have a DNSSEC-aware resolver and set VerifyHostKeyDNS to "ask" or "yes" in ~/.ssh/config, OpenSSH will verify host keys against these SSHFP records. """ Best, Li-Wen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 blocks of data, varying both blocks in the process. This makes SHA-1 unsuitable for digital signatures. A *third-party* attacker cannot create a bogus torrent using a collision attack against SHA-1 because the attacker would need to match a specific hash value. What may be possible is that the creator of the legitimate torrent might create two torrents with the same hash, but this seems very contrived and not very useful. It has all sorts of problems as a way of delivering targeted malware. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 > ed25519). I plan to do that sometime this coming week. I wonder if it > would be a good idea for FreeBSD to do the same The draft FreeBSD Git docs have the SSH fingerprints of the Git servers. https://github.com/bsdimp/freebsd-git-docs/blob/main/URLs.md Here's one from my own ~/.ssh/known_hosts: SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE git.freebsd.org (ED25519) -- Christian "naddy" Weisgerber na...@mips.inka.de ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 MITM attack users at will, feed them bogus infohash, > isos, git repo tofu, pkg, etc. MITM is bad, MITM is in use, > and MITM fails when sig'd, verified, and pinned. There's also nation states that require use of a nation state-owned root CA cert so that they can MITM every single SSL/TLS connection. Connections that don't use/support their custom trusted root cert are either blocked or reported (or both). In this case, MITM isn't theoretically broken, it's broken in practice. And, it's broken in the worst case scenario: downloading source code that the nation state can modify in-transit. This is why I asked FreeBSD to provide anonymous read-only ssh:// support for git. I'm very grateful they support it. I also use it for HardenedBSD's sync scripts due to my own distrust of browser-based SSL/TLS PKI, even in the USA. 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 ed25519). I plan to do that sometime this coming week. I wonder if it would be a good idea for FreeBSD to do the same (note: I'm not trying to commit FreeBSD to do any work; I'm just spitballing ideas.) Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
> 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 tofu, pkg, etc. MITM is bad, MITM is in use, and MITM fails when sig'd, verified, and pinned. > Yes, someone could vandalize the wiki page but I'm now > subscribed and will notice it... Only if they go through your front door. > Also, magnet links are not officially supported the project. > provide them because I think it's useful, and there are some people > who request them... transmission-bt, aria2, etc fast, easy, distributed sharing. But needs backed by real sigs. > It's difficult to educate people on these points.. Especially when poor examples to observe and learn from continue among infrastructures and even educators. > snapaid was designed to make it even easier... So they've learned some provider specific edge tool, not general gpg, or even wider security. Oh well. > Is there any reason to think [bittorrent] insecure? Cost under $50k of compute to break sha-1, multiply that by SolarWinds size distribution clouds under tofu, collect your winnings based on your node count. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 back > > to a signer to the degree therein, caveat their platform security, > > caveat sha-1 inside torrent still being abuseable by third party, > > caveat etc > One of the large parts of security is that not everyone knows the > in's and out's of security, so people who don't know, will have heard > that SHA-1 is a cryptographic hash, and assume that something is > secure when using it. Is there any reason to think it's insecure? Even if a collision attack can be make to work against bittorrent, the attacker would need to have control over the contents of the legitimate torrent as well as the bogus one. It wouldn't be "abuseable by third party". ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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, > caveat sha-1 inside torrent still being abuseable by third party, > caveat etc. With no torrent.asc there is nothing directly saying > the torrent file / infohash itself went through freebsd project. > Whether torrent or git or else, there can be useable scope > and case for such "stronger over weaker" constructions. There is already HTTPS to protect the "authenticity" of the magnet link. Yes, someone could vandalize the wiki page but I'm now subscribed and will notice it... Also, magnet links are not officially supported the project.. I provide them because I think it's useful, and there are some people who request them... One of the large parts of security is that not everyone knows the in's and out's of security, so people who don't know, will have heard that SHA-1 is a cryptographic hash, and assume that something is secure when using it. It's difficult to educate people on these points.. > gpg offers better hash algos than sha-1 these days, > all users should look into configuring and using it, > same goes for abandoning the old [a]symmetric algos > and weaker keys, made with old weak /dev/random, etc. > > One cannot sign or verify anything without knowing gpg first :) snapaid was designed to make it even easier... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
>> 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 given object format (hash algorithm) for the repository. The valid values are sha1 and (if enabled) sha256. sha1 is the default. > continue to test how well it works and monitor the > ecosystem for a transition in a few years when it is robust.. Sure, though perhaps freebsd may then find to enjoy a more middle lead, ahead than the rather later move of svn->git, and being already git it will be far less work. There should be some freebsd press release when the current git deploy is all done, as new people from outside will like to know last big OS is on git and then use it more too. > 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, caveat sha-1 inside torrent still being abuseable by third party, caveat etc. With no torrent.asc there is nothing directly saying the torrent file / infohash itself went through freebsd project. Whether torrent or git or else, there can be useable scope and case for such "stronger over weaker" constructions. gpg offers better hash algos than sha-1 these days, all users should look into configuring and using it, same goes for abandoning the old [a]symmetric algos and weaker keys, made with old weak /dev/random, etc. One cannot sign or verify anything without knowing gpg first :) And even port called "age" is of simple utility too. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 |know the tree is modified is a real problem... SHA-256 arrives, if you look at the git history. Until then signing a git tag even with SHA-1 is better than being unsealed. Actually, no it is not. It provides a false sense a security. SHA-1 should only be used as a checksum (detecting non-malicous corruption) now. There's a reason I stopped signing (and even removed the historical signatures) of the magnet links that I produce for FreeBSD. This is also why I expanded the snapaid tool to support releases, to make it extermely easy to verify signatures: https://www.funkthat.com/gitea/jmg/snapaid This attack, well, interesting that FreeBSD with so many developers with ssh push hasn't been soiled more often. I am And that is why it isn't a major problem yet, in that there are additional layers of security, both ssh and https that help ensure integrity of the repo in transit... cautious regarding such, there is a tremendous amount of propaganda against Russia and China going on .. and then who tapped the cables, who has the budget, hmm. I have read one US national security alert report once, and all i could see was I am well aware of this, and infact, the reason I've been pushing for better security like this IS because of the actions of the NSA... I used to get lunch on a weekly basis across the street from one of the early revealed NSA wiretap rooms. OK I've been pondering this since last night. If this is a reasonable concern, and given all that's already gone into coercing git into something FreeBSD friendly. Is it reasonable to consider putting all that effort that's already been excreted, and what would need to be done. To cobble up a FreeBSD version? [tongue-in-cheek] fuk-git -- FreeBSDUsersCare-git. Sorry. It's a strain. But I needed face-palm; that was: fuc-git. A failed attempt at wit. :-( the rest holds true. that acronym. Seriously tho. It wouldn't be that hard to provide sha384(1) at a minimum. Better; hmac-sha384, or any of a number of other digests. I'm just thinking that if everyone pitched in, what with all the other work that's already been done. It'd all get done on a timeline that wouldn't leave the FreeBSD repo unsafe. Mind you; much of this is all conceptual. But I just thought (hoped) it might be worth while. --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 real problem... SHA-256 arrives, if you look at the git history. Until then signing a git tag even with SHA-1 is better than being unsealed. Actually, no it is not. It provides a false sense a security. SHA-1 should only be used as a checksum (detecting non-malicous corruption) now. There's a reason I stopped signing (and even removed the historical signatures) of the magnet links that I produce for FreeBSD. This is also why I expanded the snapaid tool to support releases, to make it extermely easy to verify signatures: https://www.funkthat.com/gitea/jmg/snapaid This attack, well, interesting that FreeBSD with so many developers with ssh push hasn't been soiled more often. I am And that is why it isn't a major problem yet, in that there are additional layers of security, both ssh and https that help ensure integrity of the repo in transit... cautious regarding such, there is a tremendous amount of propaganda against Russia and China going on .. and then who tapped the cables, who has the budget, hmm. I have read one US national security alert report once, and all i could see was I am well aware of this, and infact, the reason I've been pushing for better security like this IS because of the actions of the NSA... I used to get lunch on a weekly basis across the street from one of the early revealed NSA wiretap rooms. OK I've been pondering this since last night. If this is a reasonable concern, and given all that's already gone into coercing git into something FreeBSD friendly. Is it reasonable to consider putting all that effort that's already been excreted, and what would need to be done. To cobble up a FreeBSD version? [tongue-in-cheek] fuk-git -- FreeBSDUsersCare-git. Sorry. It's a strain. But I needed that acronym. Seriously tho. It wouldn't be that hard to provide sha384(1) at a minimum. Better; hmac-sha384, or any of a number of other digests. I'm just thinking that if everyone pitched in, what with all the other work that's already been done. It'd all get done on a timeline that wouldn't leave the FreeBSD repo unsafe. Mind you; much of this is all conceptual. But I just thought (hoped) it might be worth while. --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 look at the git history. Until then > signing a git tag even with SHA-1 is better than being unsealed. Actually, no it is not. It provides a false sense a security. SHA-1 should only be used as a checksum (detecting non-malicous corruption) now. There's a reason I stopped signing (and even removed the historical signatures) of the magnet links that I produce for FreeBSD. This is also why I expanded the snapaid tool to support releases, to make it extermely easy to verify signatures: https://www.funkthat.com/gitea/jmg/snapaid > This attack, well, interesting that FreeBSD with so many > developers with ssh push hasn't been soiled more often. I am And that is why it isn't a major problem yet, in that there are additional layers of security, both ssh and https that help ensure integrity of the repo in transit... > cautious regarding such, there is a tremendous amount of > propaganda against Russia and China going on .. and then who > tapped the cables, who has the budget, hmm. I have read one US > national security alert report once, and all i could see was I am well aware of this, and infact, the reason I've been pushing for better security like this IS because of the actions of the NSA... I used to get lunch on a weekly basis across the street from one of the early revealed NSA wiretap rooms. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 the tree is questionable anyways. |> |> git uses the hardened SHA-1 for sure, which is, as far as i know, |> at least safe against the known attack. |> I .. have not tracked this, but i think upgrading to SHA-256 is |> possible, once this will become standard. Just even more |> metadata, then. I have not looked into this, still in progress. | |A new attack came out earlier this year: |https://eprint.iacr.org/2020/014.pdf Impressive document. Not a mathematician here, but still. |>From the paper: |> In particular, chosen-prefix collisions can break signature schemes and |> handshake security in secure channel protocols (TLS, SSH), if generated |> extremely quickly. | |The previous attack in 2017 did not break SHA-1 enough to render it's |use by git vulnerable, but the writing was on the wall for SHA-1... | |I believe this new attack makes git's use a SHA-1 vulnerable... |The type/length prefix that prevented the previous attacks from |working is not effective against the new attack... | |Also, the cost of the attack is not great ($45k), considering the recent Ha. |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 look at the git history. Until then signing a git tag even with SHA-1 is better than being unsealed. This attack, well, interesting that FreeBSD with so many developers with ssh push hasn't been soiled more often. I am cautious regarding such, there is a tremendous amount of propaganda against Russia and China going on .. and then who tapped the cables, who has the budget, hmm. I have read one US national security alert report once, and all i could see was a supposed russian who logged into an open management console, and immediately logged out again (if the session was printed correctly). On some software where this login possibility was publicly announced as being a problem months before. (I read around once i read this report.) So given that the software would at least log such login attempts it could even have been seen as a kind reminder, whatever. Maybe not. Was it "national security alert"?, i think yes. Well. It is always easy to point with fingers at someone else. But as always, situation is horror. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 tree is questionable anyways. > > > > git uses the hardened SHA-1 for sure, which is, as far as i know, > > at least safe against the known attack. > > I .. have not tracked this, but i think upgrading to SHA-256 is > > possible, once this will become standard. Just even more > > metadata, then. I have not looked into this, still in progress. > > A new attack came out earlier this year: > https://eprint.iacr.org/2020/014.pdf > > From the paper: > > In particular, chosen-prefix collisions can break signature schemes and > > handshake security in secure channel protocols (TLS, SSH), if generated > > extremely quickly. > > The previous attack in 2017 did not break SHA-1 enough to render it's > use by git vulnerable, but the writing was on the wall for SHA-1... > > I believe this new attack makes git's use a SHA-1 vulnerable... > The type/length prefix that prevented the previous attacks from > working is not effective against the new attack... > > Also, the cost of the attack is not great ($45k), considering the recent > 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... > Yea. The git transition team knew about these issues (though the referenced paper is new). Too bad git's SHA-256 stuff is too immature to use yet at scale, coupled with requiring a super new git version to even test it out. Plus, much of the greater git ecosystem simply doesn't support SHA-256 yet. We should, as a project, continue to test how well it works and monitor the ecosystem for a transition in a few years when it is robust... Warner -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 for sure, which is, as far as i know, > at least safe against the known attack. > I .. have not tracked this, but i think upgrading to SHA-256 is > possible, once this will become standard. Just even more > metadata, then. I have not looked into this, still in progress. A new attack came out earlier this year: https://eprint.iacr.org/2020/014.pdf >From the paper: > In particular, chosen-prefix collisions can break signature schemes and > handshake security in secure channel protocols (TLS, SSH), if generated > extremely quickly. The previous attack in 2017 did not break SHA-1 enough to render it's use by git vulnerable, but the writing was on the wall for SHA-1... I believe this new attack makes git's use a SHA-1 vulnerable... The type/length prefix that prevented the previous attacks from working is not effective against the new attack... Also, the cost of the attack is not great ($45k), considering the recent 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... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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. > > > Like if a dev starts in 2021, any commits made by that > > dev prior to 2021 should not be "valid".. Then there's also the > > issue that people's keys change over time, and now you need to know > > what time period each key was valid for, otherwise a compromised key > > could be used to insert malicious changes into your/the tree... > > If we manage keys plus their history in the doc repo, this seems > to be solved. The data is there, but are you going to write a tool such that it can be verified? Then you have the job of verifying the doc repo to make sure that the keys you have is valid, where does the root of trust come from there? Not saying it isn't possible, it's just a LOT of work to make it useful... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
> 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/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 subversion >>> to git >>> > starting this this weekend. The docs repo was moved 2 weeks ago. >>> The ports >>> > repo will move at the end of March, 2021 due to timing issues. ... >>> >>> I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when >>> clean), >>> but that's just a trivial issue with my source tree being marked -dirty >>> when it isn't, and that would have been part of r368709 anyway. All my >>> other git nits have been my own (refs/notes and origin name). >> >> Warner/others, up to r368820, we had log entries that looked like this: >> >> commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a >> Author: Li-Wen Hsu >> Date: Sun Dec 20 02:59:44 2020 + >> >> Mark the repository as being converted to Git. >> >> This is the last Subversion commit to src. >> >> Sponsored by: The FreeBSD Foundation >> >> Notes: >> svn path=/head/; revision=368820 >> >> Now, our git logs look like this: >> >> commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc >> Author: Ed Maste >> Date: Tue Dec 22 23:31:15 2020 -0500 >> >> newvers.sh: fix sense of git dirty check >> >> Previously we reported -dirty for an unmodified tree, and no >> -dirty if >> there were changes. >> >> PR: 252028 >> Reported by: John Kennedy >> >> (Specifically, no Notes: with revision= value) > > Yes, these notes are merely pointers to the SVN revisions. Without SVN, > we will of course not get any new notes. > >> For the kernel I compiled today, the uname output dumps out: >> >> FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ... >> >> Last kernel was (-dirty since fixed): >> >> FreeBSD 13.0-CURRENT #244 >> r368820+3cc0c0d66a06-c255241(main)-dirty: ... >> >> So, the r368820-value isn't being updated for it to find anymore. >> The middle >> value corresponds to the git commit and does have value (878d53410f75 >> is your >> "UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the >> repository >> as being converted to Git" r368820 commit). > > Yeah, that's a bug in newvers.sh, thanks for pointing that out. It finds > "some" note in the last 10k revs and then uses that, instead of properly > falling back to counting from HEAD, which would result in -c255126 or > something around that. I built HEAD this afternoon and got 'FreeBSD 13.0-CURRENT #0 92be2847e84-c255272(main): Wed Dec 23 17:39:31 CET 2020'. The counting seems more correct here? > We'll fix it ... > > Cheers > Uli ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 repo was moved 2 weeks ago. The ports > repo will move at the end of March, 2021 due to timing issues. ... I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when clean), but that's just a trivial issue with my source tree being marked -dirty when it isn't, and that would have been part of r368709 anyway. All my other git nits have been my own (refs/notes and origin name). Warner/others, up to r368820, we had log entries that looked like this: commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a Author: Li-Wen Hsu Date: Sun Dec 20 02:59:44 2020 + Mark the repository as being converted to Git. This is the last Subversion commit to src. Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=368820 Now, our git logs look like this: commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc Author: Ed Maste Date: Tue Dec 22 23:31:15 2020 -0500 newvers.sh: fix sense of git dirty check Previously we reported -dirty for an unmodified tree, and no -dirty if there were changes. PR: 252028 Reported by:John Kennedy (Specifically, no Notes: with revision= value) Yes, these notes are merely pointers to the SVN revisions. Without SVN, we will of course not get any new notes. For the kernel I compiled today, the uname output dumps out: FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ... Last kernel was (-dirty since fixed): FreeBSD 13.0-CURRENT #244 r368820+3cc0c0d66a06-c255241(main)-dirty: ... So, the r368820-value isn't being updated for it to find anymore. The middle value corresponds to the git commit and does have value (878d53410f75 is your "UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the repository as being converted to Git" r368820 commit). Yeah, that's a bug in newvers.sh, thanks for pointing that out. It finds "some" note in the last 10k revs and then uses that, instead of properly falling back to counting from HEAD, which would result in -c255126 or something around that. We'll fix it ... Cheers Uli ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 move at the end of March, 2021 due to timing issues. ... > > I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when clean), > but that's just a trivial issue with my source tree being marked -dirty > when it isn't, and that would have been part of r368709 anyway. All my > other git nits have been my own (refs/notes and origin name). Warner/others, up to r368820, we had log entries that looked like this: commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a Author: Li-Wen Hsu Date: Sun Dec 20 02:59:44 2020 + Mark the repository as being converted to Git. This is the last Subversion commit to src. Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=368820 Now, our git logs look like this: commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc Author: Ed Maste Date: Tue Dec 22 23:31:15 2020 -0500 newvers.sh: fix sense of git dirty check Previously we reported -dirty for an unmodified tree, and no -dirty if there were changes. PR: 252028 Reported by:John Kennedy (Specifically, no Notes: with revision= value) For the kernel I compiled today, the uname output dumps out: FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ... Last kernel was (-dirty since fixed): FreeBSD 13.0-CURRENT #244 r368820+3cc0c0d66a06-c255241(main)-dirty: ... So, the r368820-value isn't being updated for it to find anymore. The middle value corresponds to the git commit and does have value (878d53410f75 is your "UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the repository as being converted to Git" r368820 commit). How do you plan on referencing distinct patches now? If the revision number is going away, we might as well yank it out since it'll be r368820 forever. For my git projects, I often use a "git tag -a" (annotated) commit at useful milestones, but I'm not sure what you're using it for: [git describe] vendor/bc/3.2.3-255270-g3f3cc995a35a ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 can improve it using git-worktree. If I understand git-worktree(1) correctly I will most probably not need it, because I will only follow one single branch stable/12, and soon stable/13. Or do I miss something important? You are correct. You can clone stable/12 now and when it's time just do # git checkout stable/13 -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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. If I understand git-worktree(1) correctly I will most probably not need it, because I will only follow one single branch stable/12, and soon stable/13. Or do I miss something important? Thanks and regards, Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 > > I think the answer is a simple "git checkout NEW". This will replace the > current tree at branch OLD with the contents of branch NEW. Thanks to all of you pointing me away from renaming a branch instead of simply checking out the branch of interest. > git branch -m is different and changes what the branch means. If you did > what you suggested then you'd be renaming the OLD brnach to NEW, which > isn't what I think you're asking about. No, I will not apply anything before having it understood. In this case I looked into git-branch(1) because I believed this the command to be. Haven't found git-checkout(1) :-( Sorry for the noise. Now, stable/13 may come, I am ready to switch ;-) Thanks again and regards, Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 > https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md form > your other mail I was able to migrate from svn to git without running into > any issues. > > Right now I am learning how to use git the way I sed svn before. I am just > following 12-STABLE in order to build world and kernel. I am not > developing, neither am I committing. > > I wonder how one would switch from a currently used branch (OLD) to > another branch (NEW). > > 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 > > 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 remember the branch >renaming. If exists, -M must be used to force the > rename to >happen. > > I don't understand that text completely, because I don't know what a > reflog is, yet ;-) > > Thus: Should I use "-m" or "-M" in my scenario when switching from > stable/12 to stable/13 in the near future? > I think the answer is a simple "git checkout NEW". This will replace the current tree at branch OLD with the contents of branch NEW. git branch -m is different and changes what the branch means. If you did what you suggested then you'd be renaming the OLD brnach to NEW, which isn't what I think you're asking about. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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:
> > |>>> I hope we don't have to start signing all commits. saltstack/salt has
> > |>>> that policy, and it's extremely annoying.
> > |>
> > |>> Have to? Not currently. As with all process changes, there will be
> > |>> community discussion around the different points.
> > |>
> > |>> Warner
> > |>
> > |> I hope not!
> > |>
> > |> Signatures, at least in email messages, are just an annoyance as \
> > |> I see them.
> > |>
> > |> I don't even know how do sign an email message or make use of a
> > signatur\
> > |> e in a message I receive.
> > |>
> > |> I have never made a commit to a repository, so would not be familiar \
> > |> with signatures there; imagine it would be a barrier.
> > |
> > |Signed commits have no practicl effect on users of a repo.
> >
> > Well you can verify integrity of a repository regardless of how it
> > was distributed, this is why it is done, right.
> >
> > #?0$ git log --oneline --show-signature -1 v14.9.20.ar
> > 16a21755 (...)
> > gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
> > gpg:using RSA key DF082F6AEEC8C2FF
> > gpg: Good signature from "Steffen Nurpmeso "
> > Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12
> >
> > #?0$ git tag -v v14.9.20.ar; echo $?
> > object 16a21755fd1fade2b15fdb78a592f12169c3453f
> > type commit
> > tag v14.9.20.ar
> > tagger Steffen Nurpmeso 1607816624 +0100
> >
> > Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12
> > gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
> > gpg:using RSA key DF082F6AEEC8C2FF
> > gpg: Good signature from "Steffen Nurpmeso "
> > 0
>
> TL;DR I don't see any reason for devs to sign commits.
>
> I could see use for RE (or another entity) to occasionally (weekly?)
> sign the repo (say COPYRIGHT or UPDATING), and it would be nice for
> them to sign all the tags used for releases, but having every dev
> would both make the dev's life difficult...
I think RE signing releases makes some sense. Routine signing of commits
eliminates lots of potentially useful workflows if you also want linear
history. In particular it makes it impractical to implement any form of
commit-automatically-after-CI type workflows because rebase looses the
signature.
-- Brooks
signature.asc
Description: PGP signature
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 ago. The > ports > > repo will move at the end of March, 2021 due to timing issues. > > > > The short version is that we're switching the version control we're > using. > > This switch will preserve much of the current FreeBSD development > workflow. > > After the switch, the subversion repo will become almost read-only. All > > future work will be done in git, however as a transition aide we'll be > > replaying the MFCs to stable/11, stable/12 and the related releng > branches > > for the life of those branches. > > > > For more detailed information, please see > > https://github.com/bsdimp/freebsd-git-docs/ for the current > documentation. > > > > Please see https://wiki.freebsd.org/git for the latest detailed schedule > > (please note that this schedule is subject to change). > > > > Warner > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > > Will the project utilize gitatributes(5) to support ident as $Id:$ in > git repository? > There are no plans. $Id$, as implemented in git, records the wrong information. Rather than a commit hash, it's the blob object hash which can be hard to puzzle out. It would cause way more confusion were we to use it. Plus, when I did experiments with it, it was slow and difficult to work with. Given these issues, we've opted to not use it. Plus there's no documented way to change $Id$ to $FreeBSD$ in an easy way, and the filtering stuff looked extra fragile. > In file header, we have now only $FreeBSD$ since svn tags disappeared > after the transition. Adding ident tags to certain files which are > updated by mergemaster(8) or etcupdated(8) would be appreciated. > mergemaster and etcupdate can cope without them. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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:
...
|>|Signed commits have no practicl effect on users of a repo.
|>
|> Well you can verify integrity of a repository regardless of how it
|> was distributed, this is why it is done, right.
...
|TL;DR I don't see any reason for devs to sign commits.
|
|I could see use for RE (or another entity) to occasionally (weekly?)
|sign the repo (say COPYRIGHT or UPDATING), and it would be nice for
|them to sign all the tags used for releases, but having every dev
|would both make the dev's life difficult...
Sure. Signing at least releases makes a lot of sense.
Your idea of periodically sealing the tree is interesting, because
it can even be automatized (dependent on the key).
stable/ patch pumpkins could sign at least the last commit they
cherry pick back to stable, aren't ehy in distress already :)
|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... Like if a dev starts in 2021, any commits made by that
|dev prior to 2021 should not be "valid".. Then there's also the
|issue that people's keys change over time, and now you need to know
|what time period each key was valid for, otherwise a compromised key
|could be used to insert malicious changes into your/the tree...
|
|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 for sure, which is, as far as i know,
at least safe against the known attack.
I .. have not tracked this, but i think upgrading to SHA-256 is
possible, once this will become standard. Just even more
metadata, then. I have not looked into this, still in progress.
Imho: devs should show "muchos cojones".
I am sure you appreciate a daunting post, i think it is ok to
quote this post from openssl-...@openssl.org ("Re: Attribution of
pull requests in git"):
Theodore Ts'o wrote in
<20140426145907.ga1...@thunk.org>:
|On Sat, Apr 26, 2014 at 11:29:39AM +0100, Ben Laurie wrote:
|> I just noticed that if I merge a pull request, then both author and
|> committer are set to whoever made the pull request.
|
|Are you using github, or git using its standard pull request workflow?
|
|In the standard git workflow, the author and committer is set to the
|person who merged the pull. The person who requested the pull request
|is recorded in the signed git tag. For example, I recently signed a
|git tag:
|
|% git tag -s ext4_for_linus_stable
|
|
Wonderful.
|% git push ssh://gitol...@ra.kernel.org/pub/scm/linux/kernel/git/tytso/e\
|xt4.git tags/ext4_for_linus_stable
|
|
Ah yes.
Correct enough for German public law television at its best!
|% git request-pull origin git://git.kernel.org/pub/scm/linux/kernel/git/\
|tytso/ext4.git tags/ext4_for_linus_stable > /tmp/pull
|
|(I have aliases and shell scripts for most of this, but I've expanded
|all of this out for clarity.)
|
|Then I e-mailed the following to Linus, and then after he merged the
|pull request, when I pulled down his tree, tou can see the following:
|
|% git show --pretty=fuller --show-signature origin
|commit 9ac03675010a69507c0a9d832d6a722e07d35cc6
|merged tag 'ext4_for_linus_stable'
|gpg: Signature made Sun 20 Apr 2014 10:23:16 PM EDT using RSA key ID \
|C11804F0
|gpg: Good signature from "Theodore Ts'o "
|gpg: aka "Theodore Ts'o "
|gpg: aka "Theodore Ts'o "
|Merge: a798c10 0a04b24
|Author: Linus Torvalds
|AuthorDate: Sun Apr 20 20:43:47 2014 -0700
|Commit: Linus Torvalds
|CommitDate: Sun Apr 20 20:43:47 2014 -0700
...
|The advantage of doing this way is that git will detach the signature
|from the tag, and save it in the merge conflict, so years later, the
|cryptographic accountability chain is preserved in the git tree.
|
|Cheers,
Hope that helps.
I personally sign releases and (at least the head of a bunch of)
commits to [master] and [stable] (it is a git alias which does
it). Looser that i am i have a setup-privacy script on an
encrypted partition that loads keys, unfortunately not even root
can kill -SOMESIG to cause all ssh-agents etc to unload and clear
the loaded keys, therefore i hook acpi and do something like
if command -v ssh-add >/dev/null 2>&1; then
for a in /tmp/ssh-*/agent.*; do
[ -e "$a" ] || continue
act '( SSH_AUTH_SOCK="$a" ssh-add -D ) /dev/null 2>&1 &'
done
fi
Luckily i do not yet use per-user private temporary directories.
All in all it
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 , and a reflog entry is created to remember the branch renaming. If exists, -M must be used to force the rename to happen. I don't understand that text completely, because I don't know what a reflog is, yet ;-) Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to stable/13 in the near future? You should not use any options if you want to switch your working copy to new branch. `-m` and `-M` *renames* branch! I'm idiot today, it is `git checkout ` of course. -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 remember the branch renaming. If exists, -M must be used to force the rename to happen. I don't understand that text completely, because I don't know what a reflog is, yet ;-) Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to stable/13 in the near future? You should not use any options if you want to switch your working copy to new branch. `-m` and `-M` *renames* branch! -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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-docs/blob/main/mini-primer.md form your other mail I was able to migrate from svn to git without running into any issues. Right now I am learning how to use git the way I sed svn before. I am just following 12-STABLE in order to build world and kernel. I am not developing, neither am I committing. I wonder how one would switch from a currently used branch (OLD) to another branch (NEW). 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 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 remember the branch renaming. If exists, -M must be used to force the rename to happen. I don't understand that text completely, because I don't know what a reflog is, yet ;-) Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to stable/13 in the near future? git-branch is used to create/delete/rename branches. 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. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 your other mail I was able to migrate from svn to git without running into any issues. Right now I am learning how to use git the way I sed svn before. I am just following 12-STABLE in order to build world and kernel. I am not developing, neither am I committing. I wonder how one would switch from a currently used branch (OLD) to another branch (NEW). 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 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 remember the branch renaming. If exists, -M must be used to force the rename to happen. I don't understand that text completely, because I don't know what a reflog is, yet ;-) Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to stable/13 in the near future? Thanks and regards, Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 should not be "valid".. Then there's also the > issue that people's keys change over time, and now you need to know > what time period each key was valid for, otherwise a compromised key > could be used to insert malicious changes into your/the tree... If we manage keys plus their history in the doc repo, this seems to be solved. -- p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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 ago. The ports > repo will move at the end of March, 2021 due to timing issues. > > The short version is that we're switching the version control we're using. > This switch will preserve much of the current FreeBSD development workflow. > After the switch, the subversion repo will become almost read-only. All > future work will be done in git, however as a transition aide we'll be > replaying the MFCs to stable/11, stable/12 and the related releng branches > for the life of those branches. > > For more detailed information, please see > https://github.com/bsdimp/freebsd-git-docs/ for the current documentation. > > Please see https://wiki.freebsd.org/git for the latest detailed schedule > (please note that this schedule is subject to change). > > Warner > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Will the project utilize gitatributes(5) to support ident as $Id:$ in git repository? In file header, we have now only $FreeBSD$ since svn tags disappeared after the transition. Adding ident tags to certain files which are updated by mergemaster(8) or etcupdated(8) would be appreciated. Best regards, -- Marek Zarychta ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
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:
> |>>> I hope we don't have to start signing all commits. saltstack/salt has
> |>>> that policy, and it's extremely annoying.
> |>
> |>> Have to? Not currently. As with all process changes, there will be
> |>> community discussion around the different points.
> |>
> |>> Warner
> |>
> |> I hope not!
> |>
> |> Signatures, at least in email messages, are just an annoyance as \
> |> I see them.
> |>
> |> I don't even know how do sign an email message or make use of a signatur\
> |> e in a message I receive.
> |>
> |> I have never made a commit to a repository, so would not be familiar \
> |> with signatures there; imagine it would be a barrier.
> |
> |Signed commits have no practicl effect on users of a repo.
>
> Well you can verify integrity of a repository regardless of how it
> was distributed, this is why it is done, right.
>
> #?0$ git log --oneline --show-signature -1 v14.9.20.ar
> 16a21755 (...)
> gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
> gpg:using RSA key DF082F6AEEC8C2FF
> gpg: Good signature from "Steffen Nurpmeso "
> Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12
>
> #?0$ git tag -v v14.9.20.ar; echo $?
> object 16a21755fd1fade2b15fdb78a592f12169c3453f
> type commit
> tag v14.9.20.ar
> tagger Steffen Nurpmeso 1607816624 +0100
>
> Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12
> gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
> gpg:using RSA key DF082F6AEEC8C2FF
> gpg: Good signature from "Steffen Nurpmeso "
> 0
TL;DR I don't see any reason for devs to sign commits.
I could see use for RE (or another entity) to occasionally (weekly?)
sign the repo (say COPYRIGHT or UPDATING), and it would be nice for
them to sign all the tags used for releases, but having every dev
would both make the dev's life difficult...
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... Like if a dev starts in 2021, any commits made by that
dev prior to 2021 should not be "valid".. Then there's also the
issue that people's keys change over time, and now you need to know
what time period each key was valid for, otherwise a compromised key
could be used to insert malicious changes into your/the tree...
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.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On 2020-Dec-22, at 13:31, Mark Millard wrote: > On 2020-Dec-22, at 13:06, bob prohaska wrote: > >> On Tue, Dec 22, 2020 at 09:34:25PM +0100, Ronald Klop wrote: >>> >>> what does "pkg install git" do for you? NB: I use "pkg install git-lite". >>> Prevents about 1000 dependencies. >>> >> >> That seems to have worked. It reported something about package management >> not being installed, but after a prompt installed pkg-static and set >> up a version of git which seems to run. Svnlite had been working without >> this step. >> >> This is for a Pi2B v 1.1, arm v7 only. > > Ahh. As far as I know armv7 ports have been building right along. It was > arm64 that had the old build system fail as I understand. > >> Using the "mini git primer" at https://hackmd.io/hJgnfzd5TMK-VHgUzshA2g >> I tried to clone stable/12 expecting that the -beta would be gone. >> >> It looks as if I'm still jumping the gun. Although >> cgit.freegbsd.org replies to ping, using >> >> bob@www:/usr % git clone cgit.freebsd.org -b stable/12 freebsd-src >> >> reports: >> >> fatal: repository 'cgit.freebsd.org' does not exist >> >> This is just a rehearsal, so I can wait, but if I've >> made other mistakes please point them out. > > cgit.freebsd.org is not for getting clones from, just like svnweb.freebsd.org > was not for getting svn from. > > Using main as an example, not stable/12 . . . > > The bottom of the page https://cgit.freebsd.org/src/ shows 3 URL's for > use in cloning src: > > Clone > https://git.FreeBSD.org/src.git > anon...@git.freebsd.org:src.git > g...@gitrepo.freebsd.org:src.git Hmm. It turns out that the last 2 are links on that page and the links expand out to: https://cgit.freebsd.org/src/anon...@git.freebsd.org:src.git and: https://cgit.freebsd.org/src/g...@gitrepo.freebsd.org:src.git So it seems that there are ways to clone that involve referencing cgit.freebsd.org . > The last two are not explicit about notation like ssh: prefixes. > > I cloned FreeBSD's src.git via: > > git clone -o freebsd --config > remote.freebsd.fetch='+refs/notes/*:refs/notes/*' > ssh://anon...@git.freebsd.org/src.git freebsd-src > > Other than using the ssh: style, I got the command notation from > part of: > > https://github.com/bsdimp/freebsd-git-docs/blob/main/src-cvt.md > > The remote.freebsd.fetch related material allows for finding the svn version > numbers for the older content. > > Checking out stable/12 from the clone should be possible after the above, but > that is not what I've been doing. > === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On 2020-Dec-22, at 13:06, bob prohaska wrote: > On Tue, Dec 22, 2020 at 09:34:25PM +0100, Ronald Klop wrote: >> >> what does "pkg install git" do for you? NB: I use "pkg install git-lite". >> Prevents about 1000 dependencies. >> > > That seems to have worked. It reported something about package management > not being installed, but after a prompt installed pkg-static and set > up a version of git which seems to run. Svnlite had been working without > this step. > > This is for a Pi2B v 1.1, arm v7 only. Ahh. As far as I know armv7 ports have been building right along. It was arm64 that had the old build system fail as I understand. > Using the "mini git primer" at https://hackmd.io/hJgnfzd5TMK-VHgUzshA2g > I tried to clone stable/12 expecting that the -beta would be gone. > > It looks as if I'm still jumping the gun. Although > cgit.freegbsd.org replies to ping, using > > bob@www:/usr % git clone cgit.freebsd.org -b stable/12 freebsd-src > > reports: > > fatal: repository 'cgit.freebsd.org' does not exist > > This is just a rehearsal, so I can wait, but if I've > made other mistakes please point them out. cgit.freebsd.org is not for getting clones from, just like svnweb.freebsd.org was not for getting svn from. Using main as an example, not stable/12 . . . The bottom of the page https://cgit.freebsd.org/src/ shows 3 URL's for use in cloning src: Clone https://git.FreeBSD.org/src.git anon...@git.freebsd.org:src.git g...@gitrepo.freebsd.org:src.git The last two are not explicit about notation like ssh: prefixes. I cloned FreeBSD's src.git via: git clone -o freebsd --config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' ssh://anon...@git.freebsd.org/src.git freebsd-src Other than using the ssh: style, I got the command notation from part of: https://github.com/bsdimp/freebsd-git-docs/blob/main/src-cvt.md The remote.freebsd.fetch related material allows for finding the svn version numbers for the older content. Checking out stable/12 from the clone should be possible after the above, but that is not what I've been doing. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
