Re: git and the loss of revision numbers
sry forgot details: source tree @ ead01bfe8 git -C /usr/src checkout gf20c0e331 error: pathspec 'gf20c0e331' did not match any file(s) known to git what is the 'g' for? git -C /usr/src checkout f20c0e331 M sys/amd64/conf/GENERIC HEAD is now at f20c0e331 caroot: drop $FreeBSD$ expansion from root bundle yet I don't see any indication that anything changed, and now it wont update at all: git -C /usr/src pull --ff-only You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull On 12/28/20 7:56 PM, Pete Wright wrote: On 12/28/20 4:38 PM, monochrome wrote: what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src I will generally just checkout the short git hash like so in my local checkout: $ git checkout gb81783dc98e6 you can quickly get the hashes by running "git log" from your checkout. cheers, -pete ___ 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: git and the loss of revision numbers
this didn't seem to work, and now git is saying: You are not currently on a branch. since the incremental numbers aren't in the git log does it make more sense to use the short hash like this? other different responses were focused on the incremental commit number. Also, I saw someone mention that a 12 digit shortened hash is the standard to use, yet uname only spits out 9? thanks On 12/28/20 7:56 PM, Pete Wright wrote: On 12/28/20 4:38 PM, monochrome wrote: what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src I will generally just checkout the short git hash like so in my local checkout: $ git checkout gb81783dc98e6 you can quickly get the hashes by running "git log" from your checkout. cheers, -pete ___ 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: git and the loss of revision numbers
On Mon, Dec 28, 2020 at 04:56:39PM -0800, John-Mark Gurney wrote:
> monochrome wrote this message on Mon, Dec 28, 2020 at 19:38 -0500:
> > what would be the git command for reverting source to a previous version
> > using these numbers? for example, with svn and old numbers:
> > svnlite update -r367627 /usr/src
> >
> > this is needed often when it blows up for someone tracking current
>
> Get the hash from a commit number:
> $git rev-list --reverse HEAD | tail -n +255241 | head -n 1
> 3cc0c0d66a065554459bd2f9b4f80cc07426464a
>
> so:
> git checkout $(git rev-list --reverse HEAD | tail -n +255240 | head -n 1)
>
Or save a process:
git rev-list --reverse HEAD | awk 'NR == 255241 {print; exit 0}'
3cc0c0d66a065554459bd2f9b4f80cc07426464a
(And thus:
git checkout $(git rev-list --reverse HEAD | awk 'NR == 255241 {print; exit 0}')
Could also pass the number to awk via the "-v var=value" command-line.)
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
While Trump successfully conned a lot of people for a while, in the
end he's just a failure throwing a temper tantrum because he lost.
See https://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
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: git and the loss of revision numbers
monochrome wrote this message on Mon, Dec 28, 2020 at 19:38 -0500: > what would be the git command for reverting source to a previous version > using these numbers? for example, with svn and old numbers: > svnlite update -r367627 /usr/src > > this is needed often when it blows up for someone tracking current Get the hash from a commit number: $git rev-list --reverse HEAD | tail -n +255241 | head -n 1 3cc0c0d66a065554459bd2f9b4f80cc07426464a so: git checkout $(git rev-list --reverse HEAD | tail -n +255240 | head -n 1) > On 12/28/20 11:27 AM, Ed Maste wrote: > > On Mon, 28 Dec 2020 at 07:08, Renato Botelho wrote: > >> > >> FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 > >> 3cc0c0d66a0-c255241(main)-dirty: > >> ^ > >> This is an incremental counter of commits > > > > Also, uqs@ recently fixed an issue in newvers.sh (including the final, > > non-updating svn revision) and reordered the information. An example > > of the new format: > > > > main-c255126-gb81783dc98e6-dirty > > \ \ \\ > >\ \ \ local modifications > > \ \hash > > \ commit count > >branch -- 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: git and the loss of revision numbers
On 12/28/20 4:38 PM, monochrome wrote: what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src I will generally just checkout the short git hash like so in my local checkout: $ git checkout gb81783dc98e6 you can quickly get the hashes by running "git log" from your checkout. cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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: git and the loss of revision numbers
what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src this is needed often when it blows up for someone tracking current On 12/28/20 11:27 AM, Ed Maste wrote: On Mon, 28 Dec 2020 at 07:08, Renato Botelho wrote: FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 3cc0c0d66a0-c255241(main)-dirty: ^ This is an incremental counter of commits Also, uqs@ recently fixed an issue in newvers.sh (including the final, non-updating svn revision) and reordered the information. An example of the new format: main-c255126-gb81783dc98e6-dirty \ \ \\ \ \ \ local modifications \ \hash \ commit count branch ___ 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: panic: Assertion pgrp->pg_jobc > 0 failed at kern_proc.c:816
On 12/28/20 12:24 PM, John Baldwin wrote:
> I got this panic again today in a VM when quitting a gdb
> session after killing a child process via 'kill'.
>
> panic: Assertion pgrp->pg_jobc > 0 failed at
> /git/bhyve/sys/kern/kern_proc.c:816
> cpuid = 1
> time = 1609185862
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00946547f0
> vpanic() at vpanic+0x181/frame 0xfe0094654840
> panic() at panic+0x43/frame 0xfe00946548a0
> _refcount_update_saturated() at _refcount_update_saturated/frame
> 0xfe00946548e0
> killjobc() at killjobc+0x6a6/frame 0xfe0094654940
> exit1() at exit1+0x6af/frame 0xfe00946549b0
> sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe00946549c0
> amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0094654af0
> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0094654af0
> --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8024c8f0a, rsp =
> 0x7fffe358, rbp = 0x7fffe370 ---
> KDB: enter: panic
> [ thread pid 44034 tid 102484 ]
> Stopped at kdb_enter+0x37: movq$0,0x10ab066(%rip)
>
> From what I can tell, the child process that was killed via 'kill' has
> not yet exited and is stuck in ptracestop() from fork():
>
> (kgdb) where
> #0 sched_switch (td=0xfe0094001a00, flags=) at
> /git/bhyve/sys/kern/sched_ule.c:2147
> #1 0x80bf4015 in mi_switch (flags=266) at
> /git/bhyve/sys/kern/kern_synch.c:542
> #2 0x80bfeba5 in thread_suspend_switch (td=,
> p=)
> at /git/bhyve/sys/kern/kern_thread.c:1477
> #3 0x80bef04b in ptracestop (td=0xfe0094001a00, sig=17, si=0x0)
> at /git/bhyve/sys/kern/kern_sig.c:2642
> #4 0x80ba1a54 in fork_return (td=0xfe0094001a00,
> frame=0xfe0094671b00)
> at /git/bhyve/sys/kern/kern_fork.c:1106
> #5 0x80ba18b0 in fork_exit (callout=0x80ba1950
> , arg=0xfe0094001a00,
> frame=0xfe0094671b00) at /git/bhyve/sys/kern/kern_fork.c:1069
> #6
> #7 0x0008007b71aa in ?? ()
>
> kgdb can't find the panicking process due to the zombproc removal, so I will
> have to go work on kgdb to recover from that change. :(
I've come up with a shorter reproducer (original was trying to debug a perl
script
in OpenSSL's test suite).
Compile this program:
#include
#include
#include
#include
#include
#include
int
main(void)
{
pid_t pid, wpid;
pid = fork();
if (pid == -1)
err(1, "fork");
if (pid == 0) {
printf("I'm in the child\n");
exit(1);
}
printf("I'm in the parent\n");
wpid = waitpid(pid, NULL, 0);
if (wpid < 0)
err(1, "waitpid");
return (0);
}
Then in gdb do the following:
# gdb101 ./forktest
...
(gdb) catch fork
Catchpoint 1 (fork)
(gdb) r
Starting program: /mnt/forktest/forktest
Catchpoint 1 (forked process 830), _fork () at _fork.S:4
4 _fork.S: No such file or directory.
(gdb) kill
Kill the program being debugged? (y or n) y
[Inferior 1 (process 828) killed]
(gdb) quit
--
John Baldwin
___
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"
panic: Assertion pgrp->pg_jobc > 0 failed at kern_proc.c:816
I got this panic again today in a VM when quitting a gdb session after killing a child process via 'kill'. panic: Assertion pgrp->pg_jobc > 0 failed at /git/bhyve/sys/kern/kern_proc.c:816 cpuid = 1 time = 1609185862 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00946547f0 vpanic() at vpanic+0x181/frame 0xfe0094654840 panic() at panic+0x43/frame 0xfe00946548a0 _refcount_update_saturated() at _refcount_update_saturated/frame 0xfe00946548e0 killjobc() at killjobc+0x6a6/frame 0xfe0094654940 exit1() at exit1+0x6af/frame 0xfe00946549b0 sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe00946549c0 amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0094654af0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0094654af0 --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8024c8f0a, rsp = 0x7fffe358, rbp = 0x7fffe370 --- KDB: enter: panic [ thread pid 44034 tid 102484 ] Stopped at kdb_enter+0x37: movq$0,0x10ab066(%rip) >From what I can tell, the child process that was killed via 'kill' has not yet exited and is stuck in ptracestop() from fork(): (kgdb) where #0 sched_switch (td=0xfe0094001a00, flags=) at /git/bhyve/sys/kern/sched_ule.c:2147 #1 0x80bf4015 in mi_switch (flags=266) at /git/bhyve/sys/kern/kern_synch.c:542 #2 0x80bfeba5 in thread_suspend_switch (td=, p=) at /git/bhyve/sys/kern/kern_thread.c:1477 #3 0x80bef04b in ptracestop (td=0xfe0094001a00, sig=17, si=0x0) at /git/bhyve/sys/kern/kern_sig.c:2642 #4 0x80ba1a54 in fork_return (td=0xfe0094001a00, frame=0xfe0094671b00) at /git/bhyve/sys/kern/kern_fork.c:1106 #5 0x80ba18b0 in fork_exit (callout=0x80ba1950 , arg=0xfe0094001a00, frame=0xfe0094671b00) at /git/bhyve/sys/kern/kern_fork.c:1069 #6 #7 0x0008007b71aa in ?? () kgdb can't find the panicking process due to the zombproc removal, so I will have to go work on kgdb to recover from that change. :( -- John Baldwin ___ 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: git and the loss of revision numbers
On Mon, 28 Dec 2020 at 07:08, Renato Botelho wrote: > > FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 > 3cc0c0d66a0-c255241(main)-dirty: > ^ > This is an incremental counter of commits Also, uqs@ recently fixed an issue in newvers.sh (including the final, non-updating svn revision) and reordered the information. An example of the new format: main-c255126-gb81783dc98e6-dirty \ \ \\ \ \ \ local modifications \ \hash \ commit count branch ___ 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: git and the loss of revision numbers
On 24/12/20 11:15, Michael Grimm wrote: Correction: On 24. Dec 2020, at 15:11, Michael Grimm wrote: In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a larger revision number than those in advisories or notices. In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a smaller revision number than those in advisories or notices. FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 3cc0c0d66a0-c255241(main)-dirty: ^ This is an incremental counter of commits -- 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"
