Re: How do I know if my 13-stable has security patches?

[Warner Losh]

On Sat, Feb 27, 2021 at 12:15 AM Kevin Oberman  wrote:

> Well, back to a full clone. Thanks for the "--unshallow" argument, but so
> far it has failed twice. I suspect that it's my urtwn interface is bad.
> I'll swap it out tomorrow and see it that fixes it.
>
> I am a bit surprised at how little more space the full clone takes. I was
> really expecting it to be much worse. Of course, it will only grow... as
> will the sources, themselves.
>
> Warner, I suggest an immediate update to your mini-git primer. It was
> already a bit out of date, but this fix is more urgent with RC on the
> horizon. In particular, the "Repositories" at least look old to me.
>

First quick pass done. Please let me know what you think. You can suggest
edits right on the github site (they turn into pull requests) or you can
send me suggestions directly.

Warner


> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
>
> On Fri, Feb 26, 2021 at 10:55 AM Ed Maste  wrote:
>
> > On Fri, 26 Feb 2021 at 12:10, Helge Oldach  wrote:
> > >
> > > A shallow tree is about 1.6G. If you want to patch source (say, from
> > > a SA or EN) you certainly also need space for an object tree which is
> > > about 4.5G. The total is >6G.
> > >
> > > I'd say relative to the total required to build, the 1.1G "savings"
> from
> > > using a shallow versus a full tree (which is about 2.7G) isn't really
> > > worth the effort. Plus, you get the a few benefits like full commit
> > > history including comments.
> >
> > Indeed, this is a good point. We can update docs to state:
> >
> > At present a full clone is required to include the commit count in
> > uname. An existing shallow clone can be converted into a full clone by
> > running
> >
> > % git fetch --unshallow
> > ___
> > freebsd-stable@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org
> "
> >
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: How do I know if my 13-stable has security patches?

[Kevin Oberman]

Well, back to a full clone. Thanks for the "--unshallow" argument, but so
far it has failed twice. I suspect that it's my urtwn interface is bad.
I'll swap it out tomorrow and see it that fixes it.

I am a bit surprised at how little more space the full clone takes. I was
really expecting it to be much worse. Of course, it will only grow... as
will the sources, themselves.

Warner, I suggest an immediate update to your mini-git primer. It was
already a bit out of date, but this fix is more urgent with RC on the
horizon. In particular, the "Repositories" at least look old to me.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


On Fri, Feb 26, 2021 at 10:55 AM Ed Maste  wrote:

> On Fri, 26 Feb 2021 at 12:10, Helge Oldach  wrote:
> >
> > A shallow tree is about 1.6G. If you want to patch source (say, from
> > a SA or EN) you certainly also need space for an object tree which is
> > about 4.5G. The total is >6G.
> >
> > I'd say relative to the total required to build, the 1.1G "savings" from
> > using a shallow versus a full tree (which is about 2.7G) isn't really
> > worth the effort. Plus, you get the a few benefits like full commit
> > history including comments.
>
> Indeed, this is a good point. We can update docs to state:
>
> At present a full clone is required to include the commit count in
> uname. An existing shallow clone can be converted into a full clone by
> running
>
> % git fetch --unshallow
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: How do I know if my 13-stable has security patches?

[Ed Maste]

On Fri, 26 Feb 2021 at 12:10, Helge Oldach  wrote:
>
> A shallow tree is about 1.6G. If you want to patch source (say, from
> a SA or EN) you certainly also need space for an object tree which is
> about 4.5G. The total is >6G.
>
> I'd say relative to the total required to build, the 1.1G "savings" from
> using a shallow versus a full tree (which is about 2.7G) isn't really
> worth the effort. Plus, you get the a few benefits like full commit
> history including comments.

Indeed, this is a good point. We can update docs to state:

At present a full clone is required to include the commit count in
uname. An existing shallow clone can be converted into a full clone by
running

% git fetch --unshallow
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: How do I know if my 13-stable has security patches?

[Warner Losh]

On Fri, Feb 26, 2021 at 9:35 AM Ed Maste  wrote:

> On Thu, 25 Feb 2021 at 15:58, Warner Losh  wrote:
> >
> > The problem, though, can happen when you run a shallow clone or gitup to
> > get the sources and build from that. In that case the v number is bogus
> > (hmmm, we should omit it when we have a shallow clone maybe).
>
> I want to clarify one point here - the commit count is already omitted
> from uname in the case of shallow clones (as Kevin Oberman
> discovered).
>
> Shallow clones certainly have the benefit of limiting the amount of
> disk space used by the clone. Does that outweigh the loss of the
> commit count?
>
> I had a look at the size of the .git directory with different --depth
> settings:
>
> 262Mstable-13-shallow-1/.git
> 262Mstable-13-shallow-10/.git
> 262Mstable-13-shallow-100/.git
> 281Mstable-13-shallow-1000/.git
> 807Mstable-13-shallow-1/.git
>
> I think we can provide a way to include the commit count as long as
> we're willing to require some minimum clone depth, and will pursue
> this in the next while. If this works out it will make it into
> stable/13, but probably not releng/13.0.
>

The count is a count back to the first commit in the repo. There's not even
a clear design for how to accomplish that with a subset of the repo that's
been floated. It might be possible, but until we have a clearly articulated
plan, it may be a bit premature to set expectations that it might happen.

I'm happy to be proven wrong, of course, and once there's a clear way to
accomplish this that's not fragile or a large maintenance burden on the
project, I'll happily support it...

Warner
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: How do I know if my 13-stable has security patches?

[Ed Maste]

On Thu, 25 Feb 2021 at 15:58, Warner Losh  wrote:
>
> The problem, though, can happen when you run a shallow clone or gitup to
> get the sources and build from that. In that case the v number is bogus
> (hmmm, we should omit it when we have a shallow clone maybe).

I want to clarify one point here - the commit count is already omitted
from uname in the case of shallow clones (as Kevin Oberman
discovered).

Shallow clones certainly have the benefit of limiting the amount of
disk space used by the clone. Does that outweigh the loss of the
commit count?

I had a look at the size of the .git directory with different --depth settings:

262Mstable-13-shallow-1/.git
262Mstable-13-shallow-10/.git
262Mstable-13-shallow-100/.git
281Mstable-13-shallow-1000/.git
807Mstable-13-shallow-1/.git

I think we can provide a way to include the commit count as long as
we're willing to require some minimum clone depth, and will pursue
this in the next while. If this works out it will make it into
stable/13, but probably not releng/13.0.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Trying do mount a slice containing a mounted partition makes the filesystem unreadable

[Arrigo Marchiori via freebsd-stable]

Dear All,

I think I found a bug that is similar to an already reported one, but
I am not sure.

Description: when a BSD partition is mounted to / (suppose
/dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I
receive a ``strange'' error message, and from that moment the mounted
filesystem becomes unreadable.

This problem appears:
 - on a memstick built from 11.4-STABLE r369279,
 - on the ``official'' 12.2-RELEASE memstick,
both tested on amd64.

Fun fact: the problem does _not_ appear if the already-mounted
filesystem is mounted from /dev/ufs/label instead of /dev/da0s2a.

Steps to reproduce on 12.2-RELEASE
==

 1- download the official memstick image for 12.2-RELEASE-amd64 and
 flash it into a USB pen drive

 2- edit /boot/loader.conf on the memstick adding the following lines
 (needed to boot successfully on my test system):
kern.vty=sc
kern.cam.boot_delay=1
kern.cam.scsi_delay=1

 3- edit /etc/fstab on the memstick and change the root device from
 /dev/ufs/FreeBSD_Install to /dev/da0s2a

 4- boot the memstick and open a shell

 5- # mount /dev/da0s2 /mnt
mount: /dev/da0s2: No such file or directory <--- strange message!

 6- the filesystem is now unreadable! For example, trying to run some
binaries not yet in the cache:
# man
/usr/bin/man: Device not configured

If I try to reboot, the console is flooded by:

> vm_fault: pager read error, pid 1 (init)

This problem also appears on a memstick built from 11.4-STABLE
r369279. The error messages are different, but the outcome is the
same.

Expected behavior
=

If the root partition is mounted from /dev/ufs/label (i.e. you skip
step 3 above) the culprit mount command (step 5 above) gives the
following error message:

> mount: /dev/da0s2: Operation not permitted

and the system remains healty and stable.

Am I seeing PR 222948:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222948 or is it
something else?

Thank you in advance and best regards,
-- 
Arrigo

http://rigo.altervista.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: How do I know if my 13-stable has security patches?

[Karl Denninger]

On 2/26/2021 10:22, Ed Maste wrote:

On Thu, 25 Feb 2021 at 16:57, Karl Denninger  wrote:

The time (and present items) on a given machine to know whether it is
covered by a given advisory under the "svn view of the world" is one
command, and no sources.  That is, if the advisory says "r123456" has
the fix, then if I do a "uname -v" and get something larger, it's safe.

Yes, as previously stated the commit count will be included in future
advisories.

On stable/13 today uname will include:
uname displays e.g. stable/13-n244688-66308a13dddc

The advisory would report stabl/13-n244572

244688 is greater than 244572 so will have the fix.

Sounds like the issue has been addressed -- thank you!
--
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: How do I know if my 13-stable has security patches?

[Ed Maste]

On Thu, 25 Feb 2021 at 16:57, Karl Denninger  wrote:
>
> The time (and present items) on a given machine to know whether it is
> covered by a given advisory under the "svn view of the world" is one
> command, and no sources.  That is, if the advisory says "r123456" has
> the fix, then if I do a "uname -v" and get something larger, it's safe.

Yes, as previously stated the commit count will be included in future
advisories.

On stable/13 today uname will include:
uname displays e.g. stable/13-n244688-66308a13dddc

The advisory would report stabl/13-n244572

244688 is greater than 244572 so will have the fix.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"