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"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On 2020-Dec-22, at 10:39, bob prohaska 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. >> > > Is there some way to obtain git on a Pi2B running > 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692 > without installing the ports tree? I expected > to find git in base, but it isn't there. > > Can it be found under another package name? > git in base would have licensing issues. Pi2B: v1.1 (armv7 only)? v1.2 running armv7 FreeBSD? v1.2 running arm64 FreeBSD? It does appear that arm64 ports builds have started again, or are at least being experimented with . . . Filling the Built search field with "/git" at: http://ampere2.nyi.freebsd.org/build.html?mastername=head-arm64-default=p557699_s368500 shows that devel/git built. The context looks to be: FreeBSD head -r368500 was used to as the context the builds were for. Ports head -r557699 was the vintage of the ports tree build. This is for head-arm64-default, not a quarterly build. It also shows devel/git@lite as having been built --and devel/git@gui and devel/git@tiny and devel/git-lfs and so on. The page also reports: Queued Built Failed Skipped Ignored Remaining 32987 28781 304 3106796 0 Load Averages SwapinfoElapsed Pkg/HourImpulse ( 4%) 1.31 1.40 1.664.41% 142:17:22 205 -- It is the only modern arm64 build that I found with anywhere near 28781 ports built. Looks like this is for well after head -r365692 . Unfortunately, https://pkg-status.freebsd.org/builds?type=package does not yet seem to include ampere2.nyi.freebsd.org based builds. === 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 Dec 22, 2020, at 1:39 PM, bob prohaska 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. >> > > Is there some way to obtain git on a Pi2B running > 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692 > without installing the ports tree? I expected > to find git in base, but it isn't there. > > Can it be found under another package name? > > Thanks for reading, and any guidance! Git (and git-lite) are available only in ports/packages at the moment. For those wanting to track src via git, you need to install it from there. I believe any plans for a git-compatible tool in base would be derived from Got (devel/got) due to licensing. But, unless I'm mistaken, there is no need to install git to be able to continue to get copies of src. It's only developers who need to commit changes to src that need to switch over to git in the near future. Just as FreeBSD's src has been made available as a Git repository from the canonical Subversion repo (e.g., on GitHub), I'm sure the reverse will be true for some time and you'll be able to continue to get src updates via Subversion. That would surely be the case for existing releases (otherwise it would be a huge POLA violation). I track NetBSD src via Git, even though that project currently officially uses CVS. Cheers, Paul. ___ 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
Attributions are really confusing at this point... On 2020-Dec-22, at 13:06, bob prohaska wrote: > bob@www:/usr % git clone cgit.freebsd.org -b stable/12 freebsd-src On 2020-Dec-22, at 13:31, Mark Millard wrote: > 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 Bob, like mark, I replicated -CURRENT from git by: cd /usr/src git clone -o freebsd --config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' \ anon...@git.freebsd.org:src.git . git config pull.ff only git pull -v Special callout... that "-o freebsd" and the "--config remote.freebsd.fetch" are related (changing the origin label), and if you don't have them in sync you won't pull down the refs/notes, so you git logs won't have all the details and some of the detailed info (rev, commit Id, total refs) won't show up normally. I don't think https was working when I initially tried, but this worked. ___ 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 22 Dec 2020, at 22:50, Mark Millard wrote: On 2020-Dec-22, at 13:31, Mark Millard wrote: 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 . No, that’s just a configuration bug in cgit. I’m sure it’ll get fixed in due course. The text version of the links is the correct version. Best regards, Kristof ___ 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 12:19:03PM -0800, Mark Millard wrote: > > git in base would have licensing issues. > I gather you're referring to GPLv2. A sticky wicket. The trouble with ports is the tree is getting awfully big. The host in question has a 32 GB disk and is over half full with just a base source installation. Adding a "dormant" ports tree will take nearly 2 GB, most of which is not used. Might there be some way to clone a "sparse tree" including only one port, which then leafs out just enough to build that port and dependencies? When the ports system was introduced it seemed a marvel of compactness and efficiency. Time marches on. > Pi2B: v1.1 (armv7 only)? v1.2 running armv7 FreeBSD? > v1.2 running arm64 FreeBSD? > Sorry for the ambiguity... It's v1.1, armv7 only. That's why I want to test git on this particular machine. Git seems to work fine on the Pi3. Thanks for replying! bob prohaska ___ 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 22 Dec 2020, at 22: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. > > 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 > That’s because you have the wrong URL for the src repo. Try `git clone https://git.FreeBSD.org/src.git -b stable/12 freebsd-src` Best regards, Kristof ___ 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 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. 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. Thanks for your help! bob prohaska ___ 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
Van: bob prohaska Datum: 22 december 2020 19:38 Aan: freebsd-...@freebsd.org CC: FreeBSD Current Onderwerp: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend 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. > Is there some way to obtain git on a Pi2B running 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692 without installing the ports tree? I expected to find git in base, but it isn't there. Can it be found under another package name? Thanks for reading, and any guidance! bob prohaska ___ freebsd-...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org" what does "pkg install git" do for you? NB: I use "pkg install git-lite". Prevents about 1000 dependencies. Regards, Ronald ___ 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 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. > Is there some way to obtain git on a Pi2B running 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692 without installing the ports tree? I expected to find git in base, but it isn't there. Can it be found under another package name? Thanks for reading, and any guidance! bob prohaska ___ 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 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). ___ 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
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
--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 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 signature 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. -- Brooks signature.asc Description: PGP signature
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On 2020-12-17 21:53, 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 signature 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. Tom ___ 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" I'm not a FreeBSD committer, but on other git projects I sign my commits. AFAIK it's a good idea. I'm curious what is annoying about it? It's just adding the 'sign' tag. If you want a portable GPG key check out something like a yubikey. I'm sure there's other portable hardware options. # git commit -S -m "message" You can also set to always sign automatically, # git config --global commit.gpgsign true -- Waitman Gobble ___ 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
> > 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 signature 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. Tom ___ 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
I tried cloning with the following result: [root@STING /home/filippo]# git clone -o freebsd -b main https://git.freebsd.org/src.git /usr/src Cloning into '/usr/src'... fatal: repository 'https://git.freebsd.org/src.git/' not found Should I wait past the weekend to clone?Filippo On Thursday, December 17, 2020, 8:53:22 PM GMT+1, Alan Somers wrote: On Thu, Dec 17, 2020 at 12:06 PM Warner Losh wrote: > On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn > wrote: > > > > > > > On 12/16/20 7:46 PM, Warner Losh wrote: > > > 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" > > > > > > > One question I didn't see in the (excellent!) docs is whether we should > > be PGP-signing commits or not. Is that encouraged? > > > > We've not started doing that in general. I don't think signing would cause > issues, but since it is a bit of an unknown, we've not taken a position on > this. > > Warner (on behalf of the git working group) > I hope we don't have to start signing all commits. saltstack/salt has that policy, and it's extremely annoying. -Alan ___ 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 Thu, 2020-12-17 at 13:39:09 -0700, Warner Losh wrote: On Thu, Dec 17, 2020 at 12:53 PM Alan Somers wrote: On Thu, Dec 17, 2020 at 12:06 PM Warner Losh wrote: On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn One question I didn't see in the (excellent!) docs is whether we should > be PGP-signing commits or not. Is that encouraged? > We've not started doing that in general. I don't think signing would cause issues, but since it is a bit of an unknown, we've not taken a position on this. Warner (on behalf of the git working group) 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. If you've successfully pushed your commit into FreeBSD.org infra, you've essentially signed it with a working SSH key. Isn't that enough? 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 Thu, Dec 17, 2020 at 12:53 PM Alan Somers wrote: > On Thu, Dec 17, 2020 at 12:06 PM Warner Losh wrote: > >> On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn > > >> wrote: >> >> > >> > >> > On 12/16/20 7:46 PM, Warner Losh wrote: >> > > 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" >> > > >> > >> > One question I didn't see in the (excellent!) docs is whether we should >> > be PGP-signing commits or not. Is that encouraged? >> > >> >> We've not started doing that in general. I don't think signing would cause >> issues, but since it is a bit of an unknown, we've not taken a position on >> this. >> >> Warner (on behalf of the git working group) >> > > 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 ___ 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 17, 2020 at 12:06 PM Warner Losh wrote: > On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn > wrote: > > > > > > > On 12/16/20 7:46 PM, Warner Losh wrote: > > > 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" > > > > > > > One question I didn't see in the (excellent!) docs is whether we should > > be PGP-signing commits or not. Is that encouraged? > > > > We've not started doing that in general. I don't think signing would cause > issues, but since it is a bit of an unknown, we've not taken a position on > this. > > Warner (on behalf of the git working group) > I hope we don't have to start signing all commits. saltstack/salt has that policy, and it's extremely annoying. -Alan ___ 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 17, 2020 at 12:01 PM Nathan Whitehorn wrote: > > > On 12/16/20 7:46 PM, Warner Losh wrote: > > 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" > > > > One question I didn't see in the (excellent!) docs is whether we should > be PGP-signing commits or not. Is that encouraged? > We've not started doing that in general. I don't think signing would cause issues, but since it is a bit of an unknown, we've not taken a position on this. Warner (on behalf of the git working group) ___ 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 12/16/20 7:46 PM, Warner Losh wrote: 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" One question I didn't see in the (excellent!) docs is whether we should be PGP-signing commits or not. Is that encouraged? -Nathan ___ 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 17, 2020 at 11:33 AM Andreas Ott wrote: > Hi, > > On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: > > This switch will preserve much of the current FreeBSD development > workflow. > > After the switch, the subversion repo will become almost read-only. > > Will there be an update to the build from source instructions in > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > ? > Yes, eventually. There's also a transition to asciidoc going on in doc land, and I didn't want to make it harder by churning things for them while that was in progress. > I am also interested in a (one-time) migration procedure from svn or > svnlite to git, primarily for my servers that are tracking -CURRENT. > I've put together some docs on this. https://github.com/bsdimp/freebsd-git-docs/ has them all. https://github.com/bsdimp/freebsd-git-docs/blob/main/src-cvt.md has the specifics, but I'm still polishing it. It has the basics, but the examples still need work. The tl;dr version, though, is that you'll have to pull a fresh tree from the git repo once we make the cutover and then use git to update that tree. Other than that, the rest of the instructions are the same. If you have local changes, then https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md also has some details beyond the basics. 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
Hi, On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: > This switch will preserve much of the current FreeBSD development workflow. > After the switch, the subversion repo will become almost read-only. Will there be an update to the build from source instructions in https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html ? I am also interested in a (one-time) migration procedure from svn or svnlite to git, primarily for my servers that are tracking -CURRENT. Thanks, andreas -- Andreas Ott K6OTT +1.408.431.8727 andr...@naund.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"
