Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

2021-01-01 Thread Poul-Henning Kamp 
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: Terminal colours in current

2021-01-01 Thread Hartmann, O. 
On Sat, 2 Jan 2021 08:40:55 +0300
Rozhuk Ivan  wrote:

> On Sat, 2 Jan 2021 06:33:55 +0100
> "Hartmann, O."  wrote:
> 
> > Colour settings seem to be broken since a couple of months. Out of
> > the blue, coloured kernel messages vanished - this problem is on 12
> > as well as CURRENT (we're running 12.2-RELENG, 12-STABLE and CURRENT).
> >   
> 
> I do no see problem on stable 12.
> Also current with loaders from 12 is OK.


That is interesting!


pgpsdPoF1b_2N.pgp
Description: OpenPGP digital signature

Re: Terminal colours in current

2021-01-01 Thread Rozhuk Ivan 
On Sat, 2 Jan 2021 06:33:55 +0100
"Hartmann, O."  wrote:

> Colour settings seem to be broken since a couple of months. Out of
> the blue, coloured kernel messages vanished - this problem is on 12
> as well as CURRENT (we're running 12.2-RELENG, 12-STABLE and CURRENT).
> 

I do no see problem on stable 12.
Also current with loaders from 12 is OK.

___
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: Terminal colours in current

2021-01-01 Thread Hartmann, O. 
On Sat, 2 Jan 2021 08:25:49 +0300
Rozhuk Ivan  wrote:

> Hi!
> 
> I am tring current and found that kernel options:
> options   TERMINAL_NORM_ATTR  = (FG_GREEN|BG_BLACK) # def to
> SC_NORM_ATTR / 2 | 0x00 options   TERMINAL_KERN_ATTR  =
> (FG_YELLOW|BG_BLACK) # def to SC_KERNEL_CONS_ATTR / 14 / 0x00 does not work 
> anymore.
> 
> Fast greping sources give me loader tunables:
> teken.fg_color="2"#
> teken.bg_color="0"#
> 
> but these optios does not allow set kernel messages colour.
> 
> https://www.freebsd.org/cgi/man.cgi?query=vt=0=4=FreeBSD+13.0-current=default=html
> say that TERMINAL_NORM_ATTR and TERMINAL_KERN_ATTR should work.
> Also it say that I should have:
>  kern.vt.color..rgb=""
>  kern.vt.fb.default_mode="x"
>  kern.vt.fb.modes.="x"
> but I only get:
> kern.vty: vt
> kern.vt.splash_cpu_duration: 10
> kern.vt.splash_cpu_style: 2
> kern.vt.splash_ncpu: 0
> kern.vt.splash_cpu: 0
> kern.vt.kbd_panic: 0
> kern.vt.kbd_debug: 0
> kern.vt.kbd_reboot: 0
> kern.vt.kbd_poweroff: 0
> kern.vt.kbd_halt: 0
> kern.vt.suspendswitch: 0
> kern.vt.deadtimer: 15
> kern.vt.debug: 0
> kern.vt.enable_bell: 0
> kern.vt.enable_altgr: 1
> 
> 
> Do I miss something?
> 
> ___
> 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"

Colour settings seem to be broken since a couple of months. Out of the blue, 
coloured
kernel messages vanished - this problem is on 12 as well as CURRENT (we're 
running
12.2-RELENG, 12-STABLE and CURRENT).

Kind regards,

O. Hartmann


pgpc_F9oFxSaR.pgp
Description: OpenPGP digital signature

Terminal colours in current

2021-01-01 Thread Rozhuk Ivan 
Hi!

I am tring current and found that kernel options:
options TERMINAL_NORM_ATTR  = (FG_GREEN|BG_BLACK) # def to 
SC_NORM_ATTR / 2 | 0x00
options TERMINAL_KERN_ATTR  = (FG_YELLOW|BG_BLACK) # def to 
SC_KERNEL_CONS_ATTR / 14 / 0x00
does not work anymore.

Fast greping sources give me loader tunables:
teken.fg_color="2"  #
teken.bg_color="0"  #

but these optios does not allow set kernel messages colour.

https://www.freebsd.org/cgi/man.cgi?query=vt=0=4=FreeBSD+13.0-current=default=html
say that TERMINAL_NORM_ATTR and TERMINAL_KERN_ATTR should work.
Also it say that I should have:
 kern.vt.color..rgb=""
 kern.vt.fb.default_mode="x"
 kern.vt.fb.modes.="x"
but I only get:
kern.vty: vt
kern.vt.splash_cpu_duration: 10
kern.vt.splash_cpu_style: 2
kern.vt.splash_ncpu: 0
kern.vt.splash_cpu: 0
kern.vt.kbd_panic: 0
kern.vt.kbd_debug: 0
kern.vt.kbd_reboot: 0
kern.vt.kbd_poweroff: 0
kern.vt.kbd_halt: 0
kern.vt.suspendswitch: 0
kern.vt.deadtimer: 15
kern.vt.debug: 0
kern.vt.enable_bell: 0
kern.vt.enable_altgr: 1


Do I miss something?

___
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

2021-01-01 Thread Shawn Webb 
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: mergemaster option -p

2021-01-01 Thread Graham Perrin 

On 01/01/2021 22:06, Herbert J. Skuhra wrote:


On Fri, 01 Jan 2021 21:29:45 +0100, Graham Perrin wrote:

On 01/01/2021 19:24, Herbert J. Skuhra wrote:


On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote:


…

I did try `mergemaster -p` and somehow (!) ended up with an empty
`/etc/group` file. Dug myself out of that hole, I'll prefer to
continue using etcupdate.

-m /path/to/sources
   Specify the path to the directory where you want to do the
   make(1).


Thank you, what path would you suggest?

(Given the previous weirdness, I want to make no guesses here.)

1. Your SOURCEDIR is /usr/src/freebsd-current and not /usr/src.

Unlike etcupdate mergemaster checks for Makefile1.inc in the working
directory and asks to set SOURCEDIR accordingly:

*** /usr/src was not found.
 Found Makefile.inc1 in the current directory.
 Would you like to set SOURCEDIR to /mnt2/src? [no and exit]

Did you see this prompt?



I do not recall seeing that prompt for the first run.

I do recall responding 'yes' during a subsequent run. I did not note the 
exact name of the file but Makefile.inc1 is familiar.




2. Do you have (old) files (e.g. Makefile.inc1) or directories
(e.g. etc) in /usr/src?



No. Re:  and 
 I was 
careful to remove everything before builds and installations began.




Is this problem reproducible? Does it work if use -m switch, e.g:
'mergemaster -m .' or 'mergemaster -m /usr/src/freebsd-current'?



I might experiment when I next update the system.

In the meantime, is it relevant to note that I prefer nano (not vi) for 
EDITOR and VISUAL?


IIRC – probably reproducible – after previewing the changes to 
/etc/group I keyed 'm' and that's when the on-screen weirdness began.




Herbert



Many thanks for taking an interest.

Graham

___
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

2021-01-01 Thread Li-Wen Hsu 
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: Problem compiling git from ports

2021-01-01 Thread Filippo Moretti 
 
It worked thank youFilippo
On Friday, January 1, 2021, 5:25:10 PM GMT+1, Milan Obuch 
 wrote:  
 
 On Fri, 1 Jan 2021 16:11:52 + (UTC), Filippo Moretti
 wrote:

>  
> I run again portmaster and I have the same error as previously
> reportedFilippo On Friday, January 1, 2021, 4:05:18 PM GMT+1, Filippo
> Moretti  wrote: 
>  Ufs 
> It exits with a different error:
> ===> Installing contributed scripts  
> /bin/mkdir -p
> /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib
> cp -f -R /usr/ports/devel/git/work-default/git-2.30.0/contrib/*
> /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib
> ln:
> /usr/ports/devel/git/work-default/stage/usr/local/etc/bash_completion.d//git-completion.bash:
> File exists *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/devel/git
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/devel/git
> 

I remember seeing this too. I worked around that using options:

cat /var/db/ports/devel_git/options 
# This file is auto-generated by 'make config'.
# Options for git-2.29.2
_OPTIONS_READ=git-2.29.2
_FILE_COMPLETE_OPTIONS_LIST=CONTRIB CURL CVS GITWEB GUI HTMLDOCS ICONV NLS P4 
PERL SEND_EMAIL SUBTREE SVN PCRE PCRE2 OPTIONS_FILE_SET+=CONTRIB
OPTIONS_FILE_SET+=CURL
OPTIONS_FILE_SET+=CVS
OPTIONS_FILE_UNSET+=GITWEB
OPTIONS_FILE_UNSET+=GUI
OPTIONS_FILE_UNSET+=HTMLDOCS
OPTIONS_FILE_SET+=ICONV
OPTIONS_FILE_UNSET+=NLS
OPTIONS_FILE_SET+=P4
OPTIONS_FILE_SET+=PERL
OPTIONS_FILE_SET+=SEND_EMAIL
OPTIONS_FILE_UNSET+=SUBTREE
OPTIONS_FILE_UNSET+=SVN
OPTIONS_FILE_SET+=PCRE
OPTIONS_FILE_UNSET+=PCRE2

Regards,
Milan
___
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: etcupdate failed to build new tree

2021-01-01 Thread Chris 

On 2021-01-01 11:01, Graham Perrin wrote:
At what should have been the end of my first upgrade since the transition to 
git:


cd /usr/src/freebsd-current && make installworld && etcupdate

Ĵ– concluded with a successful installworld, then a few lines about scanning 
and

skipping certificates, then:


Failed to build new tree.


I see the manual page for etcupdate(8) but I'm not sure how to proceed.



I did try `mergemaster -p` and somehow (!) ended up with an empty 
`/etc/group`

file. Dug myself out of that hole, I'll prefer to continue using etcupdate.

For years now I have always initiated a simple failsafe
# cp -Rp /etc /eetc
prior to (build|install) (world|kernel)
because you just never know. ;-)

Happy 20201!

--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: r367672 broke the NFS server

2021-01-01 Thread Rick Macklem 
The patches that I believe fix this are now committed to head.

Have a good 2021, rick


From: owner-freebsd-curr...@freebsd.org  on 
behalf of Rick Macklem 
Sent: Thursday, December 31, 2020 5:56 PM
To: Konstantin Belousov
Cc: freebsd-current@freebsd.org; Alan Somers; Kirk McKusick; Mark Johnston
Subject: Re: r367672 broke the NFS server

Just fyi, I have  put a patch up on phabricator as D27875 that seems
to fix the problem for all NFS client mounts except NFSv4.0.
NFSv4.0 will require an additional fix so that the "seqid" is
properly maintained during redos of the Open caused by
the ERELOOKUP redo.

If anyone is running a recent head kernel on a system that
NFS exports UFS file systems, please test this patch.

Peter, can you test this?

If acquiring the patch from phabricator is awkward,
just email and I will send you a copy of the patch.

Thanks, rick
ps: If possible, I'd like to commit this patch in a
 couple of days, given the FreeBSD release schedule.


From: owner-freebsd-curr...@freebsd.org  on 
behalf of Konstantin Belousov 
Sent: Thursday, December 31, 2020 6:40 AM
To: Rick Macklem
Cc: freebsd-current@freebsd.org; Alan Somers; Kirk McKusick; Mark Johnston
Subject: Re: r367672 broke the NFS server

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca


On Thu, Dec 31, 2020 at 05:16:27AM +, Rick Macklem wrote:
> Rick Macklem wrote:
> >Kostik wrote:
> > >
> > >Idea of the change is to restart the syscall at top level.  So for NFS
> > >server the right approach is to not send a response and also to not
> > >free the request mbuf chain, but to restart processing.
> > Yes. I took a look and I think restarting the operation by rolling the
> > working position in the mbuf lists back and redoing the operation
> > is feasible and easier than fixing the individual operations.
> >
> > For NFSv4, you cannot redo the entire compound, since non-idempotent
> > operations like exclusive open may have already been completed.
> > However, rolling back to the beginning of the operation should be
> > doable.
> Turned out to be quite easy. I'll stick a patch up on phabricator
> tomorrow, after I do a little more testing.
> NFSv4.0 is still broken, because it screws up the seqid, but I can
> fix that separately.
>
> I do see the code looping about 2-3 times before it gets a successful
> ufs_create(). Does that sound reasonable?
In the simple case, it could be described as is: ERELOOKUP is returned
if the parent directory cannot be locked sleep-less, and we have to drop
the lock for opened vnode to sleep on it. More elaborate (but still
not precise) description is that parent directory might also need to
be synced, in which case its parent might need to be locked, and so on
recursively.

Slightly reformulating, I expect that ERELOOKUPs come out in case several
threads create files in the same directory.

> Here's some debug printfs for the test run of 4 concurrent compiles.
> (proc=8 is create and proc=12 is remove. Each line is a ERELOOKUP
>  retry. This is for the 4 threads, but I had the thread tid in another printf
>  and it showed 2-3 attempts for the same thread. They should be serialized
>  by the exclusive lock on the directory vnode.)
I cannot make any conclusion from the output and its description.
Are there opens that do not result in ERELOOKUP, i.e. does the op
eventually succeed ?  What is the ratio of ERELOOKUP vs. success ?

Also note that any VOP that modify the volume' metadata might result
in ERELOOKUP.

> tryag3 stat=0 proc=8
> tryag3 stat=0 proc=8
___
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"
___
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: Enabling AESNI by default

2021-01-01 Thread Warner Losh 
On Fri, Jan 1, 2021, 1:40 PM Mina Galić  wrote:

> On Thursday, December 31st, 2020 at 20:51, Allan Jude <
> allanj...@freebsd.org> wrote:
>
> > We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
> >
> > I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal knowledge"
> that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), you need to load
> aesni.ko'
>
> This tribal knowledge is encoded in bsdinstall when you setup encryption
> on zfs:
>
> https://cgit.freebsd.org/src/tree/usr.sbin/bsdinstall/scripts/zfsboot#n1207


Even so, adding to GENERIC is fine.

Warner


>
> Mina
> ___
> 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: mergemaster option -m (was: etcupdate failed to build new tree)

2021-01-01 Thread Herbert J. Skuhra 
On Fri, 01 Jan 2021 21:29:45 +0100, Graham Perrin wrote:
> 
> On 01/01/2021 19:24, Herbert J. Skuhra wrote:
> 
> > On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote:
> > 
> >> …
> >> 
> >> I did try `mergemaster -p` and somehow (!) ended up with an empty
> >> `/etc/group` file. Dug myself out of that hole, I'll prefer to
> >> continue using etcupdate.
> > -m /path/to/sources
> >   Specify the path to the directory where you want to do the
> >   make(1).
> 
> 
> Thank you, what path would you suggest?
> 
> (Given the previous weirdness, I want to make no guesses here.)

1. Your SOURCEDIR is /usr/src/freebsd-current and not /usr/src.

Unlike etcupdate mergemaster checks for Makefile1.inc in the working
directory and asks to set SOURCEDIR accordingly:

*** /usr/src was not found.
Found Makefile.inc1 in the current directory.
Would you like to set SOURCEDIR to /mnt2/src? [no and exit]

Did you see this prompt?

2. Do you have (old) files (e.g. Makefile.inc1) or directories
(e.g. etc) in /usr/src?

Is this problem reproducible? Does it work if use -m switch, e.g:
'mergemaster -m .' or 'mergemaster -m /usr/src/freebsd-current'?

--
Herbert
___
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

2021-01-01 Thread RW 
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: Enabling AESNI by default

2021-01-01 Thread Mina Galić 
On Thursday, December 31st, 2020 at 20:51, Allan Jude  
wrote:

> We've had the AESNI module for quite a few years now, and it has not caused 
> any problems.
>
> I am wondering if there are any objections to including it in GENERIC, so 
> that users get the benefit without having to have the "tribal knowledge" that 
> 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), you need to load 
> aesni.ko'

This tribal knowledge is encoded in bsdinstall when you setup encryption on zfs:

https://cgit.freebsd.org/src/tree/usr.sbin/bsdinstall/scripts/zfsboot#n1207


Mina
___
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"

mergemaster option -m (was: etcupdate failed to build new tree)

2021-01-01 Thread Graham Perrin 

On 01/01/2021 19:24, Herbert J. Skuhra wrote:


On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote:


…

I did try `mergemaster -p` and somehow (!) ended up with an empty
`/etc/group` file. Dug myself out of that hole, I'll prefer to
continue using etcupdate.

-m /path/to/sources
  Specify the path to the directory where you want to do the
  make(1).



Thank you, what path would you suggest?

(Given the previous weirdness, I want to make no guesses here.)

___
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

2021-01-01 Thread Christian Weisgerber 
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: Problem compiling git from ports

2021-01-01 Thread Filippo Moretti 
 
I run again portmaster and I have the same error as previously reportedFilippo
On Friday, January 1, 2021, 4:05:18 PM GMT+1, Filippo Moretti 
 wrote:  
 
  Ufs 
It exits with a different error:
===> Installing contributed scripts
/bin/mkdir -p 
/usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib
cp -f -R /usr/ports/devel/git/work-default/git-2.30.0/contrib/* 
/usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib
ln: 
/usr/ports/devel/git/work-default/stage/usr/local/etc/bash_completion.d//git-completion.bash:
 File exists
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/devel/git
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/git

Thank youFilippo
On Friday, January 1, 2021, 3:52:33 PM GMT+1, Mateusz Guzik 
 wrote:  
 
 What filesystem is this?

Does it work if you sysctl vfs.cache_fast_lookup=0 ?

On 1/1/21, Filippo Moretti  wrote:
> I could not update git from 2.29 in my system
> [root@STING /usr/ports/devel/git]# uname -a
> FreeBSD STING 13.0-CURRENT FreeBSD 13.0-CURRENT #14
> main-c255423-gee938b20335: Wed Dec 30 10:41:00 CET 2020
> root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING  amd64
>
>
>
>
> This is the error which can be duplicatedsincerelyFilippo
>
>
>
> [root@STING /usr/ports/devel/git]# gmake[3]: 'GIT-VERSION-FILE' is up to
> date.
> gmake[3]: Leaving directory '/usr/ports/devel/git/work-default/git-2.30.0'
> sed -e '1s|#!.*/sh|#!/bin/sh|' git-subtree.sh >git-subtree
> chmod +x git-subtree
> install -d -m 755
> /usr/ports/devel/git/work-default/stage/usr/local/libexec/git-core
> install -m 755 git-subtree
> /usr/ports/devel/git/work-default/stage/usr/local/libexec/git-core
> asciidoctor -b docbook -d manpage  \
>        -agit_version=2.30.0 -I../../Documentation -rasciidoctor-extensions
> -alitdd='' git-subtree.txt
> gmake[2]: asciidoctor: No such file or directory
> gmake[2]: *** [Makefile:86: git-subtree.xml] Error 127
> gmake[2]: Leaving directory
> '/usr/ports/devel/git/work-default/git-2.30.0/contrib/subtree'
> *** Error code 2
>
> Stop.
> make[1]: stopped in /usr/ports/devel/git
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/devel/git
> [root@STING /usr/ports/devel/git]#
>
> ___
> 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"
>


-- 
Mateusz Guzik 
___
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: etcupdate failed to build new tree

2021-01-01 Thread Herbert J. Skuhra 
On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote:
> 
> At what should have been the end of my first upgrade since the
> transition to git:
> 
> cd /usr/src/freebsd-current && make installworld && etcupdate
> 
> Ĵ– concluded with a successful installworld, then a few lines about
> scanning and skipping certificates, then:
> 
> > Failed to build new tree.
> 
> I see the manual page for etcupdate(8) but I'm not sure how to proceed.

-s source  Specify an alternate source tree to use when building
   or extracting a “current” tree.  The default source
   tree is /usr/src.
   
> 
> 
> I did try `mergemaster -p` and somehow (!) ended up with an empty
> `/etc/group` file. Dug myself out of that hole, I'll prefer to
> continue using etcupdate.

-m /path/to/sources
 Specify the path to the directory where you want to do the
 make(1).

--
Herbert
___
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"

etcupdate failed to build new tree

2021-01-01 Thread Graham Perrin 
At what should have been the end of my first upgrade since the 
transition to git:


cd /usr/src/freebsd-current && make installworld && etcupdate

Ĵ– concluded with a successful installworld, then a few lines about 
scanning and skipping certificates, then:


> Failed to build new tree.

I see the manual page for etcupdate(8) but I'm not sure how to proceed.



I did try `mergemaster -p` and somehow (!) ended up with an empty 
`/etc/group` file. Dug myself out of that hole, I'll prefer to continue 
using etcupdate.

___
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: Problem compiling git from ports

2021-01-01 Thread Milan Obuch 
On Fri, 1 Jan 2021 16:11:52 + (UTC), Filippo Moretti
 wrote:

>  
> I run again portmaster and I have the same error as previously
> reportedFilippo On Friday, January 1, 2021, 4:05:18 PM GMT+1, Filippo
> Moretti  wrote: 
>   Ufs 
> It exits with a different error:
> ===> Installing contributed scripts  
> /bin/mkdir -p
> /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib
> cp -f -R /usr/ports/devel/git/work-default/git-2.30.0/contrib/*
> /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib
> ln:
> /usr/ports/devel/git/work-default/stage/usr/local/etc/bash_completion.d//git-completion.bash:
> File exists *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/devel/git
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/devel/git
> 

I remember seeing this too. I worked around that using options:

cat /var/db/ports/devel_git/options 
# This file is auto-generated by 'make config'.
# Options for git-2.29.2
_OPTIONS_READ=git-2.29.2
_FILE_COMPLETE_OPTIONS_LIST=CONTRIB CURL CVS GITWEB GUI HTMLDOCS ICONV NLS P4 
PERL SEND_EMAIL SUBTREE SVN PCRE PCRE2 OPTIONS_FILE_SET+=CONTRIB
OPTIONS_FILE_SET+=CURL
OPTIONS_FILE_SET+=CVS
OPTIONS_FILE_UNSET+=GITWEB
OPTIONS_FILE_UNSET+=GUI
OPTIONS_FILE_UNSET+=HTMLDOCS
OPTIONS_FILE_SET+=ICONV
OPTIONS_FILE_UNSET+=NLS
OPTIONS_FILE_SET+=P4
OPTIONS_FILE_SET+=PERL
OPTIONS_FILE_SET+=SEND_EMAIL
OPTIONS_FILE_UNSET+=SUBTREE
OPTIONS_FILE_UNSET+=SVN
OPTIONS_FILE_SET+=PCRE
OPTIONS_FILE_UNSET+=PCRE2

Regards,
Milan
___
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"

Problem compiling git from ports

2021-01-01 Thread Filippo Moretti 
I could not update git from 2.29 in my system
[root@STING /usr/ports/devel/git]# uname -a
FreeBSD STING 13.0-CURRENT FreeBSD 13.0-CURRENT #14 main-c255423-gee938b20335: 
Wed Dec 30 10:41:00 CET 2020 
root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING  amd64




This is the error which can be duplicatedsincerelyFilippo



[root@STING /usr/ports/devel/git]# gmake[3]: 'GIT-VERSION-FILE' is up to date.
gmake[3]: Leaving directory '/usr/ports/devel/git/work-default/git-2.30.0'
sed -e '1s|#!.*/sh|#!/bin/sh|' git-subtree.sh >git-subtree
chmod +x git-subtree
install -d -m 755 
/usr/ports/devel/git/work-default/stage/usr/local/libexec/git-core
install -m 755 git-subtree 
/usr/ports/devel/git/work-default/stage/usr/local/libexec/git-core
asciidoctor -b docbook -d manpage  \
    -agit_version=2.30.0 -I../../Documentation -rasciidoctor-extensions 
-alitdd='' git-subtree.txt
gmake[2]: asciidoctor: No such file or directory
gmake[2]: *** [Makefile:86: git-subtree.xml] Error 127
gmake[2]: Leaving directory 
'/usr/ports/devel/git/work-default/git-2.30.0/contrib/subtree'
*** Error code 2

Stop.
make[1]: stopped in /usr/ports/devel/git
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/git
[root@STING /usr/ports/devel/git]# 

___
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: Problem compiling git from ports

2021-01-01 Thread Mateusz Guzik 
What filesystem is this?

Does it work if you sysctl vfs.cache_fast_lookup=0 ?

On 1/1/21, Filippo Moretti  wrote:
> I could not update git from 2.29 in my system
> [root@STING /usr/ports/devel/git]# uname -a
> FreeBSD STING 13.0-CURRENT FreeBSD 13.0-CURRENT #14
> main-c255423-gee938b20335: Wed Dec 30 10:41:00 CET 2020
> root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING  amd64
>
>
>
>
> This is the error which can be duplicatedsincerelyFilippo
>
>
>
> [root@STING /usr/ports/devel/git]# gmake[3]: 'GIT-VERSION-FILE' is up to
> date.
> gmake[3]: Leaving directory '/usr/ports/devel/git/work-default/git-2.30.0'
> sed -e '1s|#!.*/sh|#!/bin/sh|' git-subtree.sh >git-subtree
> chmod +x git-subtree
> install -d -m 755
> /usr/ports/devel/git/work-default/stage/usr/local/libexec/git-core
> install -m 755 git-subtree
> /usr/ports/devel/git/work-default/stage/usr/local/libexec/git-core
> asciidoctor -b docbook -d manpage  \
> -agit_version=2.30.0 -I../../Documentation -rasciidoctor-extensions
> -alitdd='' git-subtree.txt
> gmake[2]: asciidoctor: No such file or directory
> gmake[2]: *** [Makefile:86: git-subtree.xml] Error 127
> gmake[2]: Leaving directory
> '/usr/ports/devel/git/work-default/git-2.30.0/contrib/subtree'
> *** Error code 2
>
> Stop.
> make[1]: stopped in /usr/ports/devel/git
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/devel/git
> [root@STING /usr/ports/devel/git]#
>
> ___
> 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"
>


-- 
Mateusz Guzik 
___
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

2021-01-01 Thread Shawn Webb 
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