Re: cant login after make installworld: pam_opie.so.6 not found

[grarpamp]

On 1/6/23, Xin Li  wrote:
> Security team has discussed this a decade ago.  See
> https://www.miknet.net/security/skey-dungeon-attack/
> for technical details.

That would mean that FreeBSD knowingly left users exploitable without
doing even the "easy fix" in that article to the opie code for over a decade.
And further left opie vulnerable and present since the commit in all RELENG,
STABLE, and handbook. And did not issue a SA on it since the commit, nor
ever since the article. If attempting to claim security as reason to delete,
then FreeBSD might appear to be faulty of this. Which would present good
opportunity to consider any potential improvements to that process too.

> And this could have been avoided if user have followed source upgrade

Lockout avoided... yes maybe if users wanted to quit their opie forever
at that moment, but if not, then opie code module hasn't yet been
moved to ports for anyone to use and or update as they wish.
The nature of port security in every unix OS is 3rd-party and un-dedicated,
so that wouldn't be reason not to port such things either.

Onward :)

Re: Putting OPIE to rest (was: Re: cant login after make installworld: pam_opie.so.6 not found)

[grarpamp]

On 1/5/23, Graham Perrin  wrote:
> I recall the original email

Orthagonal as it, and some notes since neither consider any
potential gap issue or/of any perhaps whimful removal process,
nor moves forward on any of potential better alternatives to that
which were hint (port) a bit in posts even before the removal was taken.
Opie is not some hi-maint lo-api-compat legacy driver holding back
kernel dev, it's a tiny stable user app plugin that just works for decades.
Now users are posting locked out, punted to deploy non-replacements,
and can't even compile it back because code gone from trees in use.
There was hardly reason to remove it (lots of other things could be
considered "outlived usefulness" but don't get removed), and even
if so (as perhaps part of say some larger discuss on pam), there
was zero reason for the removal team not to portify it given
FreeBSD has already set good example of moving even
large/complex user apps from base to ports.
That should have, and still should be done, with opie.

Consider on that process for future,
rather than whatever is thought of some app.

Cheers.

Cc: ports, as the lo-maint hi-api-compat opie could also be
used to +1 their competitive 35k count :)

See also compat{M}x-{arch} packages.

> https://lists.freebsd.org/archives/freebsd-current/2022-September/002565.html
> https://lists.freebsd.org/archives/freebsd-hackers/2022-September/001479.html
> https://lists.freebsd.org/archives/freebsd-security/2022-September/81.html

Re: cant login after make installworld: pam_opie.so.6 not found

[grarpamp]

>> looks like the "make delete-old-libs" has deleted that lib pam_opie.so.6
>> and now I cannot pass the login prompt
>> says the error "pam_opie.so: not found

>> how can I get it back? I tried everything and nothing brought it back

> commit 0aa2700123e22c2b0a977375e087dc2759b8e980
> Differential Revision: https://reviews.freebsd.org/D36592

This appeared as perhaps an arbitrary deletion change for some
unknown non-discussed reason. Someone else posted the problems,
user features, and alternatives that would preserve and update use of
OPIE options for FreeBSD users, but again, no one discussed.
So now users are getting locked out and have one less security
option available to them in FreeBSD.

https://lists.freebsd.org/archives/freebsd-security/2022-September/
https://lists.freebsd.org/archives/freebsd-security/2022-October/

There is still good opportunity therein to restore some
implementation of it for FreeBSD.

Welcome to 2023 :)

Re: CA's TLS Certificate Bundle in base = BAD

[grarpamp]

Again, FreeBSD should not be including the bundle in base, if users
choose to, they can get it from ports or packages or wherever else.
Including such bundles exposes users worldwide to massive risks.
You need to do more gpg attestation, pubkey pinning [1], tofu, and
cert management starting from empty file... and quit trusting bundles of
hundreds of random CA's, all of which are entities who have zero duty
or care to the user, and often exist/corrupt/break to present evil [2] ...

[1]
https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d
https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3

FreeBSD pkg(8) (aka, and: fetch(3)) don't even support this simple option,
thus they're incapable of securely fetching packages, iso's, etc from
servers in re [2]. Nor does FreeBSD even post sigs over its servers pubkeys
for users to get, verify, and pin out of band. Even pubkeys were swapped out
on FreeBSD servers without announcing for users if any exploit or loss occurred
there or for some other reason. That's all bad news :( But can be fixed :)


[2]
https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections
https://www.msn.com/en-us/news/technology/mysterious-company-with-government-ties-plays-key-internet-role/ar-AA13RwPh
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/etbBho-VBQAJ

Major Web Browsers Drop Mysterious Authentication Company After Ties
To US Military Contractor Exposed

TrustCor Systems vouches for the legitimacy of websites. But its
physical address is a UPS Store in Toronto.

Mysterious company with government ties plays key internet role

An offshore company that is trusted by the major web browsers and
other tech companies to vouch for the legitimacy of websites has
connections to contractors for U.S. intelligence agencies and law
enforcement, according to security researchers, documents and
interviews.
Google’s Chrome, Apple’s Safari, nonprofit Firefox and others allow
the company, TrustCor Systems, to act as what’s known as a root
certificate authority, a powerful spot in the internet’s
infrastructure that guarantees websites are not fake, guiding users to
them seamlessly.
The company’s Panamanian registration records show that it has the
identical slate of officers, agents and partners as a spyware maker
identified this year as an affiliate of Arizona-based Packet
Forensics, which public contracting records and company documents show
has sold communication interception services to U.S. government
agencies for more than a decade.
One of those TrustCor partners has the same name as a holding company
managed by Raymond Saulino, who was quoted in a 2010 Wired article as
a spokesman for Packet Forensics.
Saulino also surfaced in 2021 as a contact for another company, Global
Resource Systems, that caused speculation in the tech world when it
briefly activated and ran more than 100 million previously dormant IP
addresses assigned decades earlier to the Pentagon. The Pentagon
reclaimed the digital territory months later, and it remains unclear
what the brief transfer was about, but researchers said the activation
of those IP addresses could have given the military access to a huge
amount of internet traffic without revealing that the government was
receiving it.
The Pentagon did not respond to a request for comment on TrustCor.
TrustCor also did not respond to a request for comment.
[Minutes before Trump left office, millions of the Pentagon’s dormant
IP addresses sprang to life]
TrustCor’s products include an email service that claims to be
end-to-end encrypted, though experts consulted by The Washington Post
said they found evidence to undermine that claim. A test version of
the email service also included spyware developed by a Panamanian
company related to Packet Forensics, researchers said. Google later
banned all software containing that spyware code from its app store.
A person familiar with Packet Forensics’ work confirmed that it had
used TrustCor’s certificate process and its email service, MsgSafe, to
intercept communications and help the U.S. government catch suspected
terrorists.
“Yes, Packet Forensics does that,” the person said, speaking on the
condition of anonymity to discuss confidential practices.
Packet Forensics counsel Kathryn Temel said the company has no
business relationship with TrustCor. She declined to say whether it
had had one previously.
The latest discovery shows how the technological and business
complexities of the internet’s inner workings can be leveraged to an
extent that is rarely revealed.
Concerns about root certificate authorities, though, have come up before.
In 2019, a security company controlled by the government of the United
Arab Emirates that had been known as DarkMatter applied to be upgraded
to top-level root authority from intermediate authority with less
independence. That followed revelations about DarkMatter hacking

Re: Status of Alder Lake support

[grarpamp]

> What is the current state of support for Alder Lake CPUs

Some opensource support and tools for managing certain
aspects of Alder Lake should be appearing before long...

https://www.tomshardware.com/news/intel-confirms-6gb-alder-lake-bios-source-code-leak-new-details-emerge

Re: Putting OPIE to rest

[grarpamp]

On 9/15/22, Dag-Erling Smørgrav  wrote:
> Neither HOTP nor TOTP require dedicated devices.
> HOTP codes are sequential and can be pre-generated...

Those aren't really their intended or advertised usage models,
nor do common implementations support those modes.
Is FreeBSD contributing and supplying ones that do?
OPIE's model already intends for and supports no-device and printout.

To emphasize and extend...
https://lists.freebsd.org/archives/freebsd-current/2022-September/002573.html

It should also be noted that the affected scope here is not just 'FreeBSD users
logging into FreeBSD shell', there are also applications out there that compile
against and use FreeBSD's libopie, some of which are in ports some are not.

OPIE does not exist as a port+package, thus re POLA for users,
it should not be removed until such time as one is provided.

Where is discussion on these.

And why isn't every other 'old, outlived, non-hipster' pam
authentication plugin being
arbitrarily removed and non-portified, such as say tacacs, radius,
krb, rhosts, etc.
And if those pam are there, why then are hip OAUTH HOTP TOTP etc type things
not added, lib-ified, etc.

Re: Putting OPIE to rest

[grarpamp]

On 9/15/22, Dag-Erling Smørgrav  wrote:
> I will be removing OPIE from the main branch within the next few days.
> It has long outlived its usefulness.  Anyone still using it should look
> into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator).
> https://reviews.freebsd.org/D36592

At least so long as PAM remains available, OPIE should be
maintained as a PAM option, and be updated.

OPIE is the only PAM that allows printing out the future
secure tokens. Old school, secure, it just works.

HOTP requires hardware, TOTP requires time,
neither are printable, both of those require some other
[hackable] hw/sw device that costs $$$ money, and
those devices all have different threat/failure/admin models
than simple paper.

If people don't like...
- The hash algo, a volunteer committer can update it to sha256.
- The list of words, a volunteer committer can update it to
read from a list of admin supplied words in:
/etc/opie_words.txt
- The number of words, a volunteer committer can add an
option to the config for that.
- The writeable state breaking in a read-only root, a volunteer
committer can add a config option to point that elsewhere.
- The randomness, a volunteer committer can update it
to modern randomness.

And if people still don't like it, then commit those simple updates,
and push it out to ports, instead of killing users use of it.

Re: Updating EFI boot loader results in boot hangup

[grarpamp]

On 8/nn/22, yet  top-posted:
> [snip]

https://www.idallen.com/topposting.html

Re: Posting netiquette: HTML, attachments etc.

[grarpamp]

> https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/eresources/_index.adoc
>
> FreeBSD Handbook: Appendix C: updates and corrections
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264754
>
> I'm glad that HTML is supported.

No, people should not be sending HTML emails to lists.
Consult history of email netiquettes to discover the many why's.

> Also, I want support for things such as PNG.

Attachments are not necessarily against such netiquettes,
but rightly tend to be administratively size limited.

> What is the possibility of getting the/a "netiquette" link in
> the FreeBSD Mailinglist footer that is already appended to all
> the messages?

There is no such footer appended to the lists, because they're bloat.
Their aims usually better done at first via signup, in quarterly, and
via the occaisional involuntary and accepted friendly cluebat.


> we are dealing with real people working with the email
> clients available to them in 2022

Same arguments was made in 1982 1992 2002 etc, and the netiquette
won validity for good reasons and is still taught trained and disciplined.
September and 2022 are no reason to abandon oneself
from those responsibilities rites and rituals of computing.


Incapable and misconfigured email list software and archives
and search are separate issues from the sending netiquette.


Yes all mail since inception of FreeBSD is supposed
to be integrated and available in raw form here...

rsync -nHaxi bit0.us-west.freebsd.org::FreeBSD-mailarchive/

...for all the good reasons mentioned previously on the lists.
Though it needs maintenance work, and also more published
on the list info webpages / handbook that were noted earlier.

Re: Posting Netiquette [ref: Threads "look definitely like" unreadable mess. Handbook project.]

[grarpamp]

>> the “> ;† and leave empty lines between your text and the original

> Seems there is a charset mismatch.
> MUA displaying nonsense
> Oh the joy of UTF-8... ;-)

https://unicode-table.com/en/sets/quotation-marks/

The pages ...

https://docs.freebsd.org/en/books/handbook/eresources/#eresources-mail
https://docs.freebsd.org/en/articles/freebsd-questions/
https://docs.freebsd.org/en/articles/mailing-list-faq/

... are intermixing standard ASCII double quotes with questionably
gratuitous choice of using left and right double quotes via UTF-8,
which then may get slaughtered by non UTF-8 enabled cut-paste,
systems, lists, gui's, desktops, apps, and MUAs along the way.

Perhaps smack the typeset within all pages back down to ASCII,
except where no standard ASCII convention is available to
substitute for symbols, ie: (c) is the fine sub for ©,
and ASCII still fits within UTF-8 meta declarations, which may
be needed for ₿ which has no ASCII substitute, and of
course for presenting non ASCII languages.

And perhaps systems can consider enabling UTF-8 if needed
to render and handle things like ₿, say for whenever foundation
gets to accepting those easy donations and crowdfunding.

No idea what the ';' in the '“> ;”' is doing there for.

A proper page would need to add a number of the missing
email formatting netiquettes (such as no HTML), and actual
photo examples of former bad chaos and new good result, etc...
to be considered a good format, subject, and addressing
netiquette guide rule page.

Consider if "FreeBSD Articles" is best hier for a page that
may becoming more often directly linked or included into
prospective list user's signup clickstream, quarterly admin,
friendly cluebat hints, etc.

And it's mostly written to apply only to -questions
when it should be completely agnostic.

So the pages may be currently serving lesser preventive
or curative use as far as lists could go.


> Unless there is a good reason to do otherwise, reply to the sender
> and to FreeBSD-questions.

Well for subscription-required-to-post lists, only list-reply
is needed... which also follows address line bloat minimization,
reduces personal reply issues, reduces "Stop copying me
direct when I'm on list", etc.


> Arguably these recommendations should be separated out into their own page.

Such soley dedicated content would make the page easier
for people to link to wherever such reference is needed.
The current pages don't, and they're bleeding [partially] duplicated
and differing guidance content across each other.

If the page was good enough, it would get picked up
by search engines and other projects.


[-current, and even -questions, could probably be dropped
now, for -doc, or wherever else is best.]

Posting Netiquette [ref: Threads "look definitely like" unreadable mess. Handbook project.]

[grarpamp]

Around 6/2x/22, Many  rammed their horribly formed
msgs upon others to parse:
> [Subject: MCE: Does this look possibly like a slot issue?]
> [snip]


Attention all list users...
Stop top-posting and bulk-quoting.
Just stop.
Go search and learn about and use the email post formatting netiquette.
For decades agreed reasons, please, just go learn and use those rules.
Your comms peers, the efficiency of the hive, the utility of archives
and search engines, and more... all thank you in advance.


Emails looking rather messy lately, just look at the photos,
improve that by raising awareness and examples of better...

FreeBSD needs to add an entire section on the
email post formatting netiquette to the Handbook,
and link it on the List Subscription pages, and in the List Welcome
emails, and even in quarterly automated administrivia post to all lists.

Make Reading Easy Again :)


[Cc'd until postmaster makes Bcc on lists work, so that useful
inclusions for others awareness can occur while maintaining
threading and helping minimize braindead cross-repliers.]

Re: USB Disk Stalls on -current

[grarpamp]

Yes, some USB hw is very flaky,
but ZFS can work great on these...

https://www.youtube.com/watch?v=7z526m1jvls
https://www.youtube.com/watch?v=dougISKs2vQ
https://vimeo.com/13758987
https://www.youtube.com/watch?v=1zIoK_9UzHk

Re: USB Disk Stalls on -current

[grarpamp]

> Feb  6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): READ(10). CDB: 28
> 00 36 69 02 6e 00 00 80 00
> Feb  6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status: CCB
> request completed with an error
> Feb  6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying command,
> 2 more tries remain

Isn't there mechanism for kernel/cam/driver to issue a
sense request to fetch and print the actual error...
assuming, which is fine, that the bus or devices aren't
already locked up, in reset, etc such that a sense
would go unfulfilled or already be cleared.

Re: [HEADSUP] Deprecation of the ftp support in pkg

[grarpamp]

Replace FTP with IPFS.

Adopt distributed cryptosystems today :)

Re: Extracting base.txz files missing flags

[grarpamp]

> Maybe you missed something - you cannot change flags when your system
> has security level (kern.securelevel) raised above 0.

Nobody missed that since anyone can
easily install default freebsd and observe...

$ sysctl kern.securelevel
kern.securelevel: -1

SECURITY(7)  - introduction to security under FreeBSD
The security levels are:
 -1Permanently insecure mode - always run the system in insecure mode.
   This is the default initial value.

Thus they have no effect as shipped.

Nor do the schg'd files posted interact jointly with
securelevels to produce more security together.
They're just a list of arbitrarily chosen anti-footshooters,
and anti-malware and other security theatre, that don't
really need to be managed by freebsd as such.
Though the handbook security section could point to some
port/pkg/mtree's if some users wanted to try making some
offerings there.

It would also be foolish to presume or suggest, without at
least continuous formal verification etc, that any of today's OS
cannot be compromised, regardless of whatever options are enabled.
Even then, you have the problem of all the secret blackbox hardware
aka CPU / NIC they all run on... #OpenFabs #OpenHW #OpenAudit .

Re: Extracting base.txz files missing flags

[grarpamp]

Flags are not security since root will bypass everything.
While some may beg for anti-footshooting, but
where might that cry end up... chflags -Rhx schg / .
Nor should freebsd fill that role when local admins
know best for and given their own individual environments.
If local tendency is to run around as root and
disrupt your filesystems so bad that even these...
> ./libexec/ld-elf.so.1
> ./libexec/ld-elf32.so.1
... get routinely wrecked, then you have bigger local
problems to work on than freebsd can help you with :)

nb: /var/empty is an ssh make install-time thing,
that mtree might have picked up, but sshd itself
doesn't check or require schg [theatre] there.

tar should probably get an extended verbose mode format
that lists all metadata that is extractable to disk, such as flags.

Re: [HEADSUP] making /bin/sh the default shell for root

[grarpamp]

> No. The system shell is supposed to make the system usable
> by the users. Actually, the real problem is that the easiest way
> to shoot one's own foot is by changing the language (say, the
> shell) spoken by default by FreeBSD.

Well, the FreeBSD system speaks sh for its own use, this is clearly
documented as the shell called by init(8), and later by rc(8),
it should probably be the root:0 entry at least for consistancy.
No other shell is called by the FreeBSD system there.
Whatever the users want for their own shells is really up
to them to decide after that.

"Default" is bit of low context word, as there is no falling
back to some shell occuring, no filling in for some missing
option, etc. Maybe use word "shipped" or "root" instead.

Everyone said they already do, and will continue to,
exec whatever shell they like, whether after login,
or by changing the entry. So in addition to the user
being ultimately responsible for their own box and usage,
this well announced entry for UPDATING cannot therein
really be responsible for any user self-shooting.

> This is non-sense.

Well, FreeBSD does not add every shell in base,
does not add every app to base, etc.
Some reasons for those limits should be obvious.
This update gives further distilling clarity by
limiting the number of shipped uid 0 entries to 1,
with that 1 being sh.

> Every unix user should know that it's
> possible to changing the used shell by using
> chsh and this includes root.

Then for every user, this update is not a problem.

> BTW, toor default to sh, not tcsh.

No one said that the toor entry does not use sh.


Cheers :)

Re: [HEADSUP] making /bin/sh the default shell for root

[grarpamp]

The system shell really only need to support the
language of the shipped scripts of the base tooling
such as rc subsystem.
If those were someday written in Greek, then the shell
serves alone, the most common expectation of any "unix"
to have there seems to be an "sh", from which users can
further customize the box in whatever ways.
Base's simplicity, perhaps that is in part why 14 would go with
sh, and no longer litter the password file with any other shells,
else base must really add and carry them all...
zoor zsh
toor tcsh
coor csh
qoor sql
poor python
boor bash
goor go
plus the entire rest of world of shellish thingies just
to satisfy. Which is obviously untenable and absurd and
causes futher legacies, maintenance, dependencies.
Where does it stop, what is the limiting definition.
Moving to just one, some type of an "sh", seems best
to resolve the question.


> The little help you get on the command line to search and repeat commands is 
> very useful compared to plain "sh".

That is in part why the sh UI appears to be getting some
nice improvements as noted in the HEADSUP / thread.
BSD users could contribute more to that effort,
or run on the systems whichever shells are preferred.


> change "Charlie &" in the gecos field to something more
> sensible, e.g. just "Superuser"

Seconded. It seems somewhat against good idea to
have expandos in and downstream with a passwd file.
This update can also help users minimize parsing and gotcha
bugs by removing some possible escaping/AND/backgrounding
interpretation problems, and reducing complexity and surface.


There's actually been a good bit of stepwise cleaning and
organization of the passwd/group file, and UID/GID
to filesystem/daemons, etc over the years.
It's good to view this as part of that effort as well.


Another problem and lost opportunity cost and burnt cycles
this update finally fixes is the decades worth of N times
a year debate on this issue. It's a cumulative friction and
waste of time. By selecting just one and sh, that goes away,
and can move forward there now too :)


> More bashism and linuxism in BSD world,
> you are waking the devil.

It was meant to say 'sh-like', bash is GPL so it shouldn't
be in BSD base, the two shells just have some common
than with *csh.

Let the beastie daemon... and its more free copyright and unique
approach to the "unix", its ongoing "pros" "innovatives" and much
more that make bsd good... boil the waterparks of linux into vaporware ;)


> Like https://github.com/shellspec/shellbench ?

Interesting tool and data :)

Re: [HEADSUP] making /bin/sh the default shell for root

[grarpamp]

> propose to make it the default shell for root starting FreeBSD 14.0-RELEASE

Make it so.

The whole rest of rc, pkg, base scripts and subsystems use a lot of sh, not csh.
So this is a good compatibility, consistancy, and gotcha-removing update,
needed for decades.

Even "bash" is a majority spoken shell in Linux/world, helping
make crossovers if BSD becomes a bit more bash-like.
The bsd sh feature updates are filling useful/needed capability gaps.

"csh considered harmful"

toor needs to go as part of simple cruft removal for a cleaner base,
else you would have to add zoor, koor, boor, toor, etc. No no no no!

Nobody leave FreeBSD just to get run csh on their windows command prompt ;)

Users are always free to customize local installs as desired.

BSD community can definitely volunteer to make benchmark of
its shell vs others, determine if and where improvements to make.
Many apps never get checked for obvious speedups,
if so it might become fastest shell even with the new features.

OpenZFS Encryption: Docs, and re Metadata Leaks

[grarpamp]

On 4/17/20, Ryan Moeller  wrote:
>
>> On Apr 17, 2020, at 4:56 PM, Pete Wright  wrote:
>>
>> On 4/17/20 11:35 AM, Ryan Moeller wrote:
>>> OpenZFS brings many exciting features to FreeBSD, including:
>>>  * native encryption
>> Is there a good doc reference on available for using this?  I believe this
>> is zfs filesystem level encryption and not a replacement for our existing
>> full-disk-encryption scheme that currently works?
>
> I’m not aware of a good current doc for this. If anyone finds/writes
> something, please post it!
> There are some old resources you can find with a quick search that do a
> pretty good job of covering the basic ideas, but I think the exact syntax of
> commands may be slightly changed in the final implementation.
>
> The encryption is performed at a filesystem level (per-dataset).


You could find some initial doc and video about zfs encryption
on openzfs.org and youtube, and in some commit logs.
Therein was mentioned...

People are needed to volunteer to expand documentation on the
zfs crypto subject further in some document committed to openzfs
repo since users and orgs will want to know it when considering use.
Volunteers are also sought by openzfs to review the crypto itself.

Maybe there was already some central place made with further
current documentation about the zfs encryption topics since then?

https://www.youtube.com/watch?v=frnLiXclAMo openzfs encryption
https://drive.google.com/file/d/0B5hUzsxe4cdmU3ZTRXNxa2JIaDQ/view
https://www.youtube.com/watch?v=kFuo5bDj8C0 openzfs encryption cloud
https://drive.google.com/file/d/14uIZmJ48AfaQU4q69tED6MJf-RJhgwQR/view

It's dataset level, so GELI or GBDE etc are needed for full coverage,
perhaps even those two may not have yet received much or formal
review either, so there is always good volunteer opportunity there
to start with review of a potentially simpler cryptosystem like those.

zfs list, dataset snapshot names properties etc not covered.

zfs history not covered, many sensitive strings will end up in
there, including cutpaste password typos into commandline,
usernames, timestamps, etc...
and no tool exist to scrub overwrite history extents with random data,
and no option exists to turn keeping of
'user initiated events' or 'long format' off,
and ultimately no option exists to tell zpool create to
disable history keeping from the very start entirely.
So maybe users have to zero disks and pools along
with it just to scrub that.

zfs also exposes these variety of path and device names,
timestamps, etc in cleartext on disk structures in various
places, including configuration cachefile...
Some of those could could be NULLed or dummied
with new zpool create options for more security
restricted use cases.

There are other meta things and tools left exposed
such as potentially any plaintext meta in send/recv.

Another big metadata leak for environments and users that
ship, sell, embed, clone, distribute, fileshare, and backup,
their raw disks pools and usbs around to untrusted third parties...
is that zfs also puts hostnames and UUID type of unique
static meta and identifying things in cleartext on disk.
zfs thus needs options to allow users to set and use a NULL,
or generic dummy default, or random string, or chosen,
"hostname" for those from the very first zpool create command.

Most applications users use, including zfs, can today
consider ways in which metadata leaks could be removed
entirely, or at least optioned out for use under
high security restricted environments modes.
That could even involve considering trading off some
extra features not actually required for a basic mode
of functionality of the app.



(cc's for fyi inclusion about leaks, and as lists still haven't
been configured to support discreet bcc for that purpose,
which would also maintain nice headers for thread following.
Gmail breaks threads. zfsonlinux topicbox peole can't subscribe
without javabloatbroken website, so someone could forward
this there. Drop non-relevant cc's from further replies.
Parent thread from freebsd current and stable lists was
Subject: OpenZFS port updated)

Re: OpenZFS port updated

[grarpamp]

On 4/17/20, Ryan Moeller  wrote:
>
>> On Apr 17, 2020, at 4:56 PM, Pete Wright  wrote:
>>
>> On 4/17/20 11:35 AM, Ryan Moeller wrote:
>>> OpenZFS brings many exciting features to FreeBSD, including:
>>>  * native encryption
>> Is there a good doc reference on available for using this?  I believe this
>> is zfs filesystem level encryption and not a replacement for our existing
>> full-disk-encryption scheme that currently works?
>
> I’m not aware of a good current doc for this. If anyone finds/writes
> something, please post it!
> There are some old resources you can find with a quick search that do a
> pretty good job of covering the basic ideas, but I think the exact syntax of
> commands may be slightly changed in the final implementation.
>
> The encryption is performed at a filesystem level (per-dataset).


You could find some initial doc and video about zfs encryption
on openzfs.org and youtube, and in some commit logs.
Therein was mentioned...

People are needed to volunteer to expand documentation on the
zfs crypto subject further in some document committed to openzfs
repo since users and orgs will want to know it when considering use.
Volunteers are also sought by openzfs to review the crypto itself.

Maybe there was already some central place made with further
current documentation about the zfs encryption topics since then?

https://www.youtube.com/watch?v=frnLiXclAMo openzfs encryption
https://drive.google.com/file/d/0B5hUzsxe4cdmU3ZTRXNxa2JIaDQ/view
https://www.youtube.com/watch?v=kFuo5bDj8C0 openzfs encryption cloud
https://drive.google.com/file/d/14uIZmJ48AfaQU4q69tED6MJf-RJhgwQR/view

It's dataset level, so GELI or GBDE etc are needed for full coverage,
perhaps even those two may not have yet received much or formal
review either, so there is always good volunteer opportunity there
to start with review of a potentially simpler cryptosystem like those.

zfs list, dataset snapshot names properties etc not covered.

zfs history not covered, many sensitive strings will end up in
there, including cutpaste password typos into commandline,
usernames, timestamps, etc...
and no tool exist to scrub overwrite history extents with random data,
and no option exists to turn keeping of
'user initiated events' or 'long format' off,
and ultimately no option exists to tell zpool create to
disable history keeping from the very start entirely.
So maybe users have to zero disks and pools along
with it just to scrub that.

zfs also exposes these variety of path and device names,
timestamps, etc in cleartext on disk structures in various
places, including configuration cachefile...
Some of those could could be NULLed or dummied
with new zpool create options for more security
restricted use cases.

There are other meta things and tools left exposed
such as potentially any plaintext meta in send/recv.

Another big metadata leak for environments and users that
ship, sell, embed, clone, distribute, fileshare, and backup,
their raw disks pools and usbs around to untrusted third parties...
is that zfs also puts hostnames and UUID type of unique
static meta and identifying things in cleartext on disk.
zfs thus needs options to allow users to set and use a NULL,
or generic dummy default, or random string, or chosen,
"hostname" for those from the very first zpool create command.

Most applications users use, including zfs, can today
consider ways in which metadata leaks could be removed
entirely, or at least optioned out for use under
high security restricted environments modes.
That could even involve considering trading off some
extra features not actually required for a basic mode
of functionality of the app.



(cc's for fyi inclusion about leaks, and as lists still haven't
been configured to support discreet bcc for that purpose,
which would also maintain nice headers for thread following.
Gmail breaks threads. zfsonlinux topicbox can't subscribe
without web. Drop non-relevant cc's from further replies.
Parent thread from freebsd current and stable lists was
Subject: OpenZFS port updated)

Re: What happen to mailing list archives?

[grarpamp]

There is also this useful and efficient form of archive/mirror to include
in the update so that it does not remain broken for too long...

https://lists.freebsd.org/pipermail/freebsd-questions/2021-June/294104.html
https://lists.freebsd.org/archives/freebsd-hubs/2021-June/00.html

Re: Arm64 Tier 1 FreeBSD 13 Phones

[grarpamp]

[cc'd for fyi, trim replies to arm]

>> https://www.pine64.org/pinephone
>> https://en.wikipedia.org/wiki/Librem_5
>> NXP i.MX 8M Quad core Cortex-A53, 64bit ARM
>>
>> https://puri.sm/products/librem-5/
>> https://en.wikipedia.org/wiki/PinePhone
>> Allwinner A64 ARM Quad core Cortex-A53
>>
>> https://www.youtube.com/watch?v=c32-QOrI4cw
>> https://www.youtube.com/watch?v=fCKMxzz9cjs
>> https://www.youtube.com/watch?v=lVJo9faE1fM
>> https://www.youtube.com/watch?v=NV0RnWorPpQ
>> https://www.fosslinux.com/43842/linux-phones-for-privacy.htm

> FreeBSD lacks the power-management infrastructure to run on
> battery-operated devices.

Management? Meh... that's what a power cable
and battery belt are for... moar power.

> linux ... code

Reference material for reverse engineering.

> developing a FreeBSD-based phone on PinePhone hardware.

FreeBSD might already runs on Pinephone...

https://dmesgd.nycbug.org/index.cgi?do=view=5574
https://twitter.com/nrgmilk_
https://twitter.com/DarkainMX/status/1282764108060717056
https://www.pine64.org/2020/07/15/july-updatepmos-ce-pre-orders-and-new-pinephone-version/
https://forum.pine64.org/showthread.php?tid=6232

https://www.reddit.com/r/PinePhoneOfficial+PINE64official+PinebookPro+PineTab/search?restrict_sr=on=(freebsd+OR+openbsd+OR+netbsd+OR+bsd)
https://www.reddit.com/r/FreeBSD+OpenBSD+NetBSD/search?restrict_sr=on=(pinephone+OR+pine64+OR+a53)
https://linuxsmartphones.com/hackers-develop-open-source-firmware-for-the-pinephone-modem-use-it-to-make-phone-calls/
https://wiki.openmoko.org/wiki/Osmocom_on_TI_Calypso
http://openbts.org/

> https://potabi.fivnex.co/development

https://github.com/fivnex
https://potabi.fivnex.co/
https://blog.fivnex.co/
https://twitter.com/potabimobile
https://discord.gg/8prEeTV
https://twitter.com/fivnex
https://fivnex.co/

> funding

https://liberapay.com/fivnex/donate

> Dream on.

These phones (boards) are growing the beginnings of a hacker culture
that is trying to get all sorts of unix to run on them, a long held dream.
And the future of phones and open hardware is only opening up more.
So whether it's Fivnex or others, do not be surprised when people
boots more kernels on them soon. Your refrigerator and car will
splash Beastie.

May your dreams hack into reality :)
___
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"

Arm64 Tier 1 FreeBSD 13 Phones

[grarpamp]

FreeBSD Phones...

https://en.wikipedia.org/wiki/Librem_5
NXP i.MX 8M Quad core Cortex-A53, 64bit ARM

https://en.wikipedia.org/wiki/PinePhone
Allwinner A64 ARM Quad core Cortex-A53

https://www.youtube.com/watch?v=c32-QOrI4cw
https://www.youtube.com/watch?v=fCKMxzz9cjs
https://www.youtube.com/watch?v=lVJo9faE1fM
https://www.youtube.com/watch?v=NV0RnWorPpQ

Happy hacking :)
___
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"

Standards: IEC Giga [re: FreeBSD image size confusion]

[grarpamp]

> is in true GBs

"true" is not a modifier of any prefix or unit in any standard,
though false GB are what's reported by USB firmware in
cheapo USB drives from some sketchy vendors ;)

> 4.5 GigaBytes means 4.5 GiB.

45 does not equal or "mean" 4831838208.

International Standards IEC (re ISO/SI/Metric)...
"giga" = "G" = decimal prefix, powers of ten, 10^, base 10 underlying
"gibi" = "Gi" = binary prefix, powers of two, 2^, base 2 underlying
There is no such prefix as "K", it's "kilo k" or "kibi Ki".
"B"yte is 8 "b"its.
RAM is in binary 2^.
Physical storage DVD/BR/USB/disk/tape/etc (quotable in decimal 10^
on the box [1]), filesystem and files UI presentation displayable in
binary prefix, use correct underlying math.
Rest in decimal 10^, including...
Network bandwidth rates... routers switches OS interfaces hardware interfacing
upstream, constant bandwidth rate managed network centric app software
[filesharing,
overlays, even packet filters]... in [kMGT...]bps ("b"its/sec) ie:
100Mbps, not the "bi"
prefixes, nor even "B"ytes... with counters in bytes not bits.
Contexts pair their associated "prefix, to base unit, to underlying math",
ie: kilometers distance (km) not kibimeters (Kim), mebibytes RAM (MiB)
not megabytes (MB), gigabps network rates (Gbps) with tier level ISPs
not gibibps (Gibps). Silly bytes per period referenced transfer notation
(B/sec, B/day, B/mon) of legacy small webhosters, and phone extortion
billing models, that all calculate and use average bitrate with upstream
already anyway... orthagonal and falling off.

Many areas in FreeBSD could be checked for representation...
prefixes for disk space using decimal G instead of binary Gi,
places under a given context (netrates or diskspace) but displaying
mixed representations across their respective utilities in base, etc.

Rockets crash due to perpetuating use of nonstandard / mix legacy.
Representations could look towards some newer formal standardization
than pre-2000's adhoc.

Linux seems to making some RAM/disk/netrates updates there with
"bi" prefixes now appearing in various places, do not know if they have
a standards conformance / base policy doc on that.

https://www.iso.org/standard/31898.html  IEC 8-13:2008
https://www.electropedia.org/iev/iev.nsf/display?openform=112-01-27
https://en.wikipedia.org/wiki/Binary_prefix
https://en.wikipedia.org/wiki/Unit_prefix

[1] Pre :2008, WDC and STX lawsuits forced more disclosure and market
consistency,
still annoying to convert box/nameplate/sector decimal <--> logical binary.
___
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 non-time-sequential logs

[grarpamp]

>Why is it that the project can't continue to operate the SVN server in
> addition to Git, gatewaying with -current as is being done with 12-stable?
> As a developer, I definitely need monotonic revision numbers and reliable
> dates when I'm trying to troubleshoot a regression. I understand that you
> want better 'collaboration' in FreeBSD, but why can't we have the best of
> both worlds?

Unlimited best worlds are already free to exist.

In addition to the internet's good suggestions how to use the
forms of "revision numbers" already in git, and the internet's
many good tutorials on how to learn, use, adopt, adapt
and live breathe git, FreeBSD has chosen git for this time.
It appears unsensible to expect any opensource
project or OS to continue operation and maintenance of
N x different repos and different repo camps in perpetuity
because minor minority seeks some small feature. A feature
in shipped code for users ok, but not in raw project overhead.
Look at the entirety of Linux and Github's thousands of big projects...
who there is leaving git these days to get number feature?
The way forward is to explore how those git projects use git to
"troubleshoot regressions" as obviously they are performing
that function well everyday, without regard to such numbers
or dates. If people find they need numbers or anything else,
they can also get together and offsite host great import "gateway"
services (or on their own locally), publish wrapper script ports,
metainfo db's, etc... those best worlds are really unlimited and
infinitely customizable as needed, so much can be done there :)
Though since FreeBSD (and almost all world of public code
repos) has chosen git and abandoned SVN etc, it's unsensible
to expect a project efficiently on one repo (FreeBSD on git) to
really interact using such N x repos within itself... it's overhead.
The good people running those N x repos will need to speak git
upstream, or at least send up patch format. That is the normal
history of [mass effect] migrations.

For more "best worlds"...
Now can call to deploy RCS too, "because" pretty version
numbers, wastes zero time on security concerns, etc.
And call to pass around tarballs on tape too, "because"
tape is reliable and can hold every revision and iso and pkg
of every OS on one 580TiB raw cart, 2+PiB compressed ;)

And as far as which of N x services to examine offsite,
rather than boring numbers, perhaps it would be more
academically interesting to learn a bit about the crypto primitives,
distribution network, and database behind some things like
https://monotone.ca/

Or anything about any other repos far more novel or
new than any of those above. Since one day people might
have to leave some formerly thought "needed" feature of git
behind in order to be carried by and follow the world into
one of those repos in the future as well. They might
even be the ones abandoning their thoughts first in order
to carry and lead others there.
___
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]

>> 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]

> 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

[grarpamp]

> 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

[grarpamp]

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

[grarpamp]

> 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: git and the loss of revision numbers

[grarpamp]

> loss of continuously increasing revision numbers

git rev-list --count HEAD
git describe --tags / parent

Plus a bunch of similar ways to do it,
from different points, in different formats,
search internet for them all... git revision version numbering...

Some deploy structured metadata in tag schemes,
use hooks, files, etc but gets messy and is not just a
simple proper read-only query.

> date of the commit besides its hash being reported
> whether to recompile

Recompilation means users have the source cloned.
Source means users can use ways like
git log 
git show
etc
Which means users have date, and a  in
log subsequent to their last compiled hash etc.
So it's not a problem beyond a few trivial steps
or shell parsing function to query and compare on
whatever particular metadata a person may like,
to what they already know they have.
The handbook will have docs on some ways.
___
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: FreeBSD: GitLab

[grarpamp]

>> I mainly asked because GitLab seems to offer a richer toolset IMHO.
>
> The project is publishing many places, and will use features of the places
> it publishes as it refines the future workflow. The different
> mirroring/hosting services offer different features and it's not yet clear
> how we can best utilize them or if even one size fits all.

As with the move to git, readonly mirrors is fine thing.
Yet more general attempt to open up bug work issue trackers flow
read-write services etc for some things beyond say central freebsd.org,
can massively raise overhead, needlessly partition knowledge
base, raise peoples search and participation time by 2^n,
complexity alienate new dev and user influx, be harder for
donors to big picture, etc...

'A: hey here's my bug report on site H'
'L: H redundant, already filed over on service X'
'Z: but we're working it on J, see the mail list at U'
'W: well J blocks devs using tor with cloudflare so we can't read or
contribute there'
'X: did you see telegram message G you can add it to site R's wiki'
'Q: nope not bothering to set up yet another account for that'
'I: ddg search gave results to U, but V which was not indexed that I
found on F had my answer'
'E: i clicked your link but N already 404 expired sold out or shutdown'
'N: , sorry for your loss'
'M: but the forum C said github clone A was it'
'O: they wanted my phone picture id and utility bill for an account, fuck that'
'B: i tried to integrate sites G and Y in my scripts to do miracle T
but they kept changing API's and it required plugins which were were
broken in pkg all month.'

Also consider before canonizing/depending elements to
third party services, especially ones without good export for
backup, mirror, and local use... people think corp services
will last forever, history shows they don't.
___
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: firewall choice

[grarpamp]

>> A full comparison would also want to note and point to

> My ipf work is documented at https://wiki.freebsd.org/IPFilter.

So links to works / pages like that from the bsd's could
also be included in the comparison wiki.
___
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: firewall choice

[grarpamp]

> in reaction to the license

Yes, license matters, and woe the history.

> It's hardly deprecated in NetBSD. Christos Zoulas and I have exchanged a
> fair bit of code.
>
> Darren Reed released and maintained IPF through the Australian National
> University. NetBSD imported it, like we do here at FreeBSD, into their src
> tree.

Past tense. Upstream appears dead, for years.

http://netbsd.org/docs/
search: deprecat

ipf (and pf) is deprecated in NetBSD in favor of npf, various
NetBSD docs, manpages, etc say this in different places and
ways, ultimately imparting in sum the shift to npf.
NPF seems the forward looking ongoing concern filter in NetBSD.

DR hasn't cut a ipf release since 5.1.2 almost a decade ago,
and all the project release websites lists for ipf appear gone.
And it's been hampered by license problems,
just like xf86, qmail, bsd, nprobe, zfs, etc.
There are cases of too much history weighing opensource projects.

Distributed maintenance and exchange is certainly cool, but ipf diffs
exist, and users should perhaps not view that model as a formal
cross platform ongoing project such as they may be accustomed to.

That actually gives rise to what a brand new clean slate startup
2-clause fully featured cross platform packet filter of the future
might look like, for at least the BSD's (maybe working on Linux
too). But that's a separate conversation.

So for now, the BSD's (and Linux) really enjoy a mashup
of filters where none have really made it cross platform
and in sync yet.

Perhaps a broad scope wiki comparison would show that,
and end up pointing out the interesting opportunity therein.
___
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: firewall choice

[grarpamp]

>>> What's the "best" [1] choice for firewalling these days
>>> There's pf, ipf and ipfw.
>>
>>This question comes up over years.
>>
>>Consider starting and joining with people to create
>>a comparison page on the FreeBSD Wiki,
>>both a feature / capability comparison table,
>>and contextual paragraphs.
>>A mini project like that can help many users
>>and add their researches to it.
>
> I'd be happy to if I knew where to start/how to start/is there a guide.

Starting a wiki is here...
https://wiki.freebsd.org/
https://wiki.freebsd.org/AboutWiki

Which falls under larger handbook doc area...
https://lists.freebsd.org/mailman/listinfo/freebsd-doc

Much of comparison would pull from man pages.

Could also come from posting a call for input / announce
to questions, hackers, forum, etc.

Wiki should not duplicate admin info from here...
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html
But would cover this handbook bullet item that is
not actually covered in the handbook (which
could link out to the wiki page for that)...
"- The differences between the firewalls built into FreeBSD."

A full comparison would also want to note and point to
upstream sources, and have a table of which filter systems
are supported going forward in each unix OS (the *BSD
flavors including DragonFly ipfw3 pf, Linux netfilter+nftables,
Illumos).

And cover layer2 capabilities, switching, bridging, ipv6,
nat, rate limits / shape / queue, proxy, arbitrary rewriting
and routing hooks, etc.

NetBSD where ipf was last released has deprecated
both ipf and pf in favor of npf. While upstream devel and
maintenance on ipf has died, pf still lives on at OpenBSD.

Anyone can start. 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: firewall choice

[grarpamp]

> What's the "best" [1] choice for firewalling these days, in the list's 
> opinion?
> There's pf, ipf and ipfw.

This question comes up over years.

Consider starting and joining with people to create
a comparison page on the FreeBSD Wiki,
both a feature / capability comparison table,
and contextual paragraphs.
A mini project like that can help many users
and add their researches to it.

> [1] up-to-date, versatile, low overhead, high throughput, IPv6-able,
> traffic shaping/queueing
___
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: Can't forward X11 apps over ssh since migrating to 13-CURRENT

[grarpamp]

Possibly check ForwardX11Timeout .
___
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: Is pkg site forbidden by brower?

[grarpamp]

On 9/6/20, Kevin Oberman  wrote:
> On Sat, Sep 5, 2020 at 8:04 PM Yoshihiro Ota  wrote:
>> Is "403 Forbidden" an intended response for a brower access to
>> http://pkg.freebsd.org/FreeBSD:12:i386/ nowdays?
>>
>> I used to see available packages with a brower and decided which one to
>> use.

Some more people have noted this change
as breaking tool scripts, etc.

And useful meta files are unfortunately now invisible:
packagesite.txz, meta.txz, pkg.txz, pkg.txz.sig

If someone want to block the '/.../All/' dir full of pkgs,
maybe, but do not block any other part of the hier.

>> How can I find distributions like "latest", "release_X", etc?

Yes, there does not appear to be any docs enumerating all
the available live names for use in PACKAGESITE url.
Reopening the above dirs would be self documenting.

The name for the term in  position of /${ABI}//All/...
might be "REPOSITORY_ROOT" or "repo-path" or simply "repository",
but it does not seem defined for users in pkg or pkg.conf manpages.
"distribution" is unlikely the correct term, "branch" might be
a useful connotation regarding ports source tree.

> Does https://pkg-status.freebsd.org/builds?jailname=121amd64 have what you
> want?

Those names don't correspond 1:1 to anything on pkg.freebsd.org.

> I can't believe that there is no way to see a log of failed builds,
> but I can only see the new failures and no information on previous builds.

Pkg buildlogs are a separate issue.
They should be available for browsing, same as kernel, base...
___
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: Plans for git (was: Please check the current beta git conversions)

[grarpamp]

> The underlying initializing 'git init' commit hash must be
> signed by security officer key having sufficient human PGP-WoT.
>
> Git also supports sha-256 soon now, adoption should
> be researched from various online article series and
> work product before committing plans...
> https://lwn.net/Articles/823352/
> https://git-scm.com/docs/hash-function-transition

For those interested, additional topical from same site...

https://github.com/bk2204/git/tree/transition-stage-4

https://lwn.net/Articles/823352/
Updating the Git protocol for SHA-256

https://lwn.net/Articles/811068/
A new hash algorithm for Git

https://lwn.net/Articles/715716/
Moving Git past SHA-1


https://lwn.net/Articles/813646/
Attestation for kernel patches

https://lwn.net/Articles/821367/
Merkle trees and build systems

https://lwn.net/Articles/663875/
Changes in the TLS certificate ecosystem, part 1

https://lwn.net/Articles/468911/
Sovereign Keys for certificate verification

https://lwn.net/Articles/652580/
Decentralization for the web
___
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"

Where's the fingerprints and sigs? (was: Please check the current beta git conversions)

[grarpamp]

On 9/1/20, Shawn Webb  wrote:
> I'm curious if there's any plans for read-only access over ssh.
> Trusting FreeBSD's ssh key material is likely easier than trusting
> HTTPS in certain regions.

A bit moot when such key materials of all services, and repos,
and ticketing, and reviews, and builds, and downloads, and
packages, forums, and git hashtree initialization first hashes, and
pubkey modulus not just the larger DER's by untrusted/attacking CA's,
etc... are all not sha-256 fingerprint signed and attested to in a base
included textfile, in repo and on website, etc by security officer keys
having good WoT... for users to reference, import, validate, pin down, etc.
And tools for accessing such services often not have fingerprint
pinning options.
Woes be to those using such untrustable massively MITM'd and
spied upon networks as the Internet, Workplace, Home, Travel,
VPN, WiFi, Tor Exits, etc not having any way to authenticate
fingerprints and pin such services back to their favorite OS
project's security apostille office yet.

Security vaunted OpenBSD still serves up via cleartext non-hashtree
anoncvs on non-ecc harware on non-zfs-skein filesystems etc...

So the BSD world must still be thought secure, bit integral, and
trustably accessible without any of these infrastructure tool
fingerprint sig and pin basics... still no need to supply them since
decades since TLS/SSH/etc were deployed...

Right?

Not.

Cheers all :)

[Same for Linux ;]
___
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: Plans for git (was: Please check the current beta git conversions)

[grarpamp]

The underlying initializing 'git init' commit hash must be
signed by security officer key having sufficient human PGP-WoT.

Git also supports sha-256 soon now, adoption should
be researched from various online article series and
work product before committing plans...
https://lwn.net/Articles/823352/
https://git-scm.com/docs/hash-function-transition
___
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: DRM Project report (week of August 10)

[grarpamp]

Thanks go to all the ongoing teams working the
things like gpgpu / compute, and graphics,
whether on-cpu-die or on-pci-card.

And even some things like BSD on Pinephone too.
https://www.pine64.org/pinephone
___
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: When will the FreeBSD (u)EFI work?

[grarpamp]

List users please adhere to email formatting netiquette
and *stop* blockquoting massive amounts of reply text,
it is not necessary, trim it out leaving only the few lines
of what you are replying to directly above your reply.
___
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"

TLS Fingerprint Pinning Needed [ex: for NFS-over-TLS client]

[grarpamp]

People appear to be talking about using and
"authenticating / verifying" TLS certs now with at least
perhaps this NFS, and certainly with other apps.

If so, it's required critical thing for the admins and users to have
the option to pin the certificate pubkey fingerprints in four ways...

- Ignore the CA chain / expiry / etc, validate only the fingerprint.
- Validate the CA chain / expiry / etc, and validate the fingerprint.
- Validate the CA chain / expiry / etc, ignore the fingeprint.
- A TOFU mode.

No application that uses TLS should be considered completely
featured and security capable without fingerprint pinning functions.

For some background reasons on why --pinnedpublickey 
implementations are now showing up in softwares that speak TLS,
and for sample code, and related infos, see the links...

https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html

https://curl.haxx.se/libcurl/c/CURLOPT_PINNEDPUBLICKEY.html
--pinnedpubkey 
Tells curl to use the specified public key file (or hashes) to verify the
peer. This can be a path to a file which contains a single public key in PEM
or DER format, or any number of base64 encoded sha256 hashes preceded by
'sha256//' and separated by ';'
When negotiating a TLS or SSL connection, the server sends a certificate
indicating its identity. A public key is extracted from this certificate and
if it does not exactly match the public key provided to this option, curl will
abort the connection before sending or receiving any data.

Please note this option is rightly more specific covering only the
isolated pubkey, not the DER form of the entire "CA signed" cert
(ie: not the typically referenced coverage of "openssl x509 -fingerprint").

When fully implemented, this enables a local admin and user environment
of more flexible certificate validation service cababilities and security model
hardening when subject to various third party things and adversaries like...

- Environment of rogue / forced / spy MITM CA's, TLS termination / proxy
cloud MITM, VPN / overlay / WiFi networks MITM, etc.
- Annoying "expired" certs awaiting tax revenue from their captured audience.
- Assigning pinned trust to intermediate CA's such as Lets Encrypt, Google,
and corporate schemes, to let edge server certs they sign be freely
rotated and or freshly signed without need to update pin.
- Avoid need to update pin every "expiry" period.
- Avoid CA's by using cert owners publicly available and out of band self
certification attestations found on keybase, social, observatories, PGP, etc.
- As mentioned above, optionally in combination with other CA / expiry / etc
checks, or ignoring the CA altogether.
- CRL checks are a massive metadata privacy and user monetization
leak that some users might not want exposed to.
- Pinning one or both of: pubkey (herein) and or CA (openssl x509 -fingerprint)

Another very useful security feature to have is a trust on first use TOFU
mode that stores, pins, and subsequently validates against those fingerprints,
similar to SSH model. This is useful for both known comms partners such as
client-server model, and in more distributed group or even p2p applications
to help keep things a bit more locked down by default.

Defense (like this pubkey pinning) in depth... you can use it :)


References (obviously TLS_1.3 is todays version to use)...

https://www.netcraft.com/internet-data-mining/ssl-survey/
https://www.ssllabs.com/ssl-pulse/
https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support-for-20-year-old-tls-1-0/
https://www.bleepingcomputer.com/news/security/ietf-approves-tls-13-as-internet-standard/
https://en.wikipedia.org/wiki/Transport_Layer_Security
https://tools.ietf.org/html/rfc8446

https://github.com/OWASP/www-community/blob/master/pages/controls/Certificate_and_Public_Key_Pinning.md
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Cheat_Sheet.md

https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d
https://github.com/curl/curl/blob/deb9462ff2de8e955c67ed441f5f48619a31198d/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3
https://github.com/curl/curl/blob/51fde337471c9125e7bf425e7ce0a0bf53691992/docs/TODO#L728
___
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: AMD Secure Encrypted Virtualization - FreeBSD Status?

[grarpamp]

>> would be really nice also to get UEFI BOOT compatible with SECURE BOOT
>> :-)
>
> Unless you are using your own BIOS, the above means getting Microsoft
> to sign boot1.efi or similar. Shims that simply work around lack of
> acceptible signature don't help.

As before in this thread, some motherboards will let you delete
the Microsoft keys from the BIOS defaults and install your own.
With those boards you do not need Microsoft, or any shims
signed by Microsoft, or anyone else but you.

See the key management parts of the UEFI SECURE BOOT spec...
https://uefi.org/

If your mobo maker does not have full key management options
in their latest BIOS, ticket and bug them until they do.
___
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/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based

[grarpamp]

On 10/4/19, Igor Mozolevsky  wrote:
> On Fri, 20 Sep 2019 at 22:01, grarpamp  wrote:
>>
>> For consideration...
>> https://lists.freebsd.org/pipermail/freebsd-security/2019-September/010099.html
>>
>> SVN really may not offer much in the way of native
>> internal self authenticating repo to cryptographic levels
>> of security against bitrot, transit corruption and repo ops,
>> external physical editing, have much signing options, etc.
>> Similar to blockchain and ZFS hash merkle-ization,
>> signing the repo init and later points tags commits,
>> along with full verification toolset, is useful function.
>
>
> 
>
> Isn't UNIX(TM) philosophy that a program should do one thing and do it
> well? Just because people can't be bothered to learn to use multiple
> tools to do *multiple* tasks on the same dataset, is not a reason, let
> alone "the reason," to increase any program complexity to orders of
> N^M^K^L so that one "foo checkout" does all the things one wants!

Was r353001 cryptosigned so people can verify it with
a second standalone multiple tool called "PGP", after the
first standalone multiple tool called "repo checkout"?
Was it crypto chained back into a crypto history so they could
treat it as a secure diff (the function of a third standalone multiple
tool "diff a b") instead of as entirely separate (and space wasting
set of) unlinked independant assertions / issuances as to a state?
How much time does that take over time each time vs
perhaps loading signed set of keys into repo client config.
Is LOGO and tape better because less complex tool than C and disk.

> When crypto invalidates a repo, how would it be different
> from seeing non ASCII characters in plain ASCII files, or sudden
> refusal to compile
> one way or another you'd still need to restore
> from BACKUP

Backup is separate, and indeed a fine practice to help
keep for when all sorts of horrors can happen.

> crypto IS NOT a substitute for good data keeping
> practices.

Who said that it was. However it can be a wrapper of
proof / certification / detection / assurance / integrity / test
over them... a good thing to have there, as opposed to nothing.

> Also, what empirical data do you have for repo bitrot/transit
> corruption that is NOT caught by underlying media?

Why are people even bothering to sha-2 or sign iso's, or
reproducible builds? There is some integrity function there.
Else just quit doing those too then.

Many sources people can find, just search...
https://www.zdnet.com/article/dram-error-rates-nightmare-on-dimm-street/
http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf
http://www.cs.toronto.edu/~bianca/papers/ASPLOS2012.pdf
https://www.jedec.org/sites/default/files/Barbara_A_summary.pdf
https://en.wikipedia.org/wiki/Data_degradation
https://en.wikipedia.org/wiki/ECC_memory
https://en.wikipedia.org/wiki/Soft_error
Already have RowHammer too, who is researching DiskHammer?
Yes, there does need to be current baseline studies made
in 2020 across all of say Google, Amazon, Facebook global
datacenters... fiber, storage, ram, etc. It is surely not zero
errors otherwise passed.

Then note all the users who do not run any media, memory,
and cables capable of detecting and or correcting garbage.
And the claims or data, about "checksums / digests / hashes"
that fall short of at least 2^128 odds that strong
crypto based repositories can provide. Many do not,
and should not, accept less as sufficient standards.
What is the worth of your data and instructions producted
with some software from some repositories from some hops.
Though error is only part of entire possible subject, still however...
Lower some risks there too by raising some crypto bars.

Be sure to expand "external physical editiing" hinted
to include malicious, even by both local and remote
adversarial actors, and or those acting outside of
established practice. Some crypto repositories require
additionally compromise of committer and or distribution
private key to impart trust downstream, all of which leaves
nice audit, instead of just sneaking in a "vi foo.rcs" or binary
equivalent.

Cryptographic defense in depth, not prayer.


[Sorry not sure which is better mail list]
___
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: AMD Secure Encrypted Virtualization - FreeBSD Status?

[grarpamp]

Although somewhat different from the virtualization part of the subject, both...

- AMD (Secure Memory Encryption, and Memory Guard) on
both EPYC and Ryzen Pro today

 and

- Intel (Multi Key Total Memory Encryption) likely on Xeon
in the near future

... also do seem to have some OS dependant bits that would
be needing configuration and awareness.

You can search them both.

This is one of Intel's papers on its version of memory encryption...

https://software.intel.com/sites/default/files/managed/a5/16/Multi-Key-Total-Memory-Encryption-Spec.pdf
___
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: AMD Secure Encrypted Virtualization - FreeBSD Status?

[grarpamp]

>> Just whose secure keys do you suggest? I go to a lot of trouble to disable
>> secure boot so I can load any operating system I want.

Some motherboards have BIOS that allows you to both
- Upload your own keys
- Delete all the spooky Microsoft keys

Read the UEFI Secure Boot specification document.
Then paste all the key management specs into a ticket
with your motherboard vendor and get on them to publish
a BIOS release that has proper key management functions.

Some BIOS makers have this as selectable options in their
BIOS reference build routines... ie: the motherboard maker doesn't
have to write any code, they just point and click, and the option
appears in a BIOS release for mobo end user customers.

Sometimes you have to bug and escalate the mobo makers
and threaten to walk your next purchase to another mobo maker
to get them to cut and post the new BIOS release.

https://www.uefi.org/
https://uefi.org/learning_center/papers
https://uefi.org/specsandtesttools
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf

https://uefi.org/sites/default/files/resources/UEFI_Secure_Boot_in_Modern_Computer_Security_Solutions_2019.pdf
https://uefi.org/sites/default/files/resources/UEFI%20Forum%20White%20Paper%20-%20Chain%20of%20Trust%20Introduction_2019.pdf


> The goal would be not to disable secure boot and have FreeBSD running
> with a secured bootloader :-)
>
> At the moment we have insecure boot + insecure kernel + possible
> encrypted data partition..

> would be really nice also to get UEFI BOOT compatible with SECURE BOOT :-)

Yes.
___
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"

AMD Secure Encrypted Virtualization - FreeBSD Status?

[grarpamp]

https://developer.amd.com/sev/
https://github.com/AMDESE/AMDSEV
https://arstechnica.com/gadgets/2019/08/a-detailed-look-at-amds-new-epyc-rome-7nm-server-cpus/
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
https://libvirt.org/kbase/launch_security_sev.html

"AMD is also using its Secure Processor to enable a couple of key
features that we believe aren't getting enough attention: Secure
Memory Encryption and Secure Encrypted Virtualization. There's an
AES-128 engine inside Epyc's memory controller, with the keys managed
by the SEP. If SME is enabled in the system BIOS, all RAM in the
system will be encrypted using a single key provided by the SEP and
decrypted when requested by the CPU. Expanding upon SME, SEV allows
guests' allocated RAM to be encrypted with individual keys, separate
from the one used by the host operating system."
___
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: LOR panic on mount -uw

[grarpamp]

On Thu, Oct 12, 2017 at 11:15 AM, John Baldwin  wrote:
> In this case the panic is separate from the LOR, and

> for a panic we really
> need the panic message in addition to the stack trace.

With release kernels stack trace appears with this
message, then it sits in ddb, forget how to print panic?

panic: access but not attached


With snapshots, both panic and stacktrace print
but it doesn't ddb and goes straight to reboot. I forget
how to make those enter ddb or 15sec countdown?

In interim..
fatal trap 12 page fault while in kernel mode
supervosor read data page not present
process = mount


I did file a ticket with script so anyone with a blank
usb stick can recreate locally.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222948
___
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: LOR panic on mount -uw

[grarpamp]

On Wed, Oct 11, 2017 at 5:18 PM, grarpamp <grarp...@gmail.com> wrote:
> Let 12.0-current r324306 amd64 efi boot from usb to installer screen,

Another way to trigger this one is
boot snapshot install media single user verbose
mdmfs -s 10m md /mnt
umount -v /mnt
[LOR stack backtrace, remains usable]
___
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"

LOR panic on mount -uw

[grarpamp]

Let 12.0-current r324306 amd64 efi boot from usb to installer screen,
try to write zeroes to an unallocated part of ada0, mount -uw a
separate part of ada0 ...

1st 0xc5ce5f0 ufs kern/vfs_mount.c:1274
2nd 0xc565b78 devfs ufs/ffs/ffs_vfsops.c:1414

db_trace_self_wrapper
vpanic
kassert_panic+0x126
g_access+0x2b9/frame 0xfe0458a31550
ffs_mount+0x1092/frame 0xfe0458a31700
vfs_donmount+0x13b8/frame 0xfe0458a31940
sys_nmount+0x72/frame 0xfe0458a31980
amd64_syscall+0x79b/frame 0xfe0458a3a1b0
Xfast_syscall+0xfb/frame 0xfe0458a31ab0
syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a88d6a, rsp =
0x7fffd428, rbp = 0x7fffd990
kdb_enter+0x3b: movq $0,kdb_why
___
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"

LORs on ctrl-alt-del and halt

[grarpamp]

FYI two repeatable LOR's...

Let 12.0-current r324306 amd64 efi boot from usb to installer screen,
do nothing but hit ctrl-alt-del...

1st 0x7f028e0 filedesc structure kern/sys_generic.c:1490
2nd 0x7da8068 devfs kern/vfs_vnops.c:1524

Let 12.0-current r324306 amd64 efi boot from usb to installer screen,
do nothing but switch to alt-f4 ttyv3, enter halt...

1st 0x7d4d9a0 ufs kern/vfs_mount.c:1274
2nd 0x79d3240 devfs kern/vfs_subr.c:2606
___
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"

Resolver needs bind to src IP option

[grarpamp]

I looked through these pages and did not see
an option to bind the resolver query from a specific
IP address (as in the case where you have multiple
interfaces and/or alias addresses and wish to pick
one instead of the default route).

resolver(3)
gethostbyname(3)
resolver(5) [resolv.conf]

You could steer them with NAT filter, or bind a local
unbound/named to a src IP and point the resolver at that.
But those seem heavier weight solutions than
doing it in the resolver natively (whether in resolv.conf
or in library calls by applications [where in the apps case,
resolv.conf would decide whether application call or
resolv.conf takes precedence]).

Thoughts?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

FreeBSD crypto and security meta

[grarpamp]

 https://lists.freebsd.org/pipermail/freebsd-security/2013-October/007226.html

http://www.freebsd.org/news/status/report-2013-07-2013-09.html#AES-NI-Improvements-for-GELI
http://www.freebsd.org/news/status/report-2013-07-2013-09.html#Reworking-random(4)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Time to kill fdc ?

[grarpamp]

 When was the last time anybody tried that with a FreeBSD release ?

Routinely :) Often archiving piles of floppies as images too.
Imagine the legacy gaming crowd does this as well to use, while preventing loss.
Also, fdformat(1), fdcontrol(8), fdread(1), and fdwrite(1) are important
complimentary tools for people too! I even use fdformat -F.

 I intend to dust of my axe and cut it from the tree later this spring.

Please don't. I also think there are motherboards still shipping with
real floppy interfaces.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

7+ days of dogfood

[grarpamp]

 sgk
 So, I decided to test FreeBSD-10 under a user desktop condition.  In
 so doing, I upgraded the circa August 2012 FreeBSD-current that ran
 on my Dell Latitude D530 (which ran rock-solid) to top-of-tree.  This
 included re-installing all ports under the pkgng paradigm.

 phk
 First a hat-tip for even doing this in the first place, if more
 committers ran -current, -current would work better.

Though not making any particular suggestion, the OpenBSD folks
have gained similar benefit from eating their own dog food as well.
You can search for something like OpenBSD Release Engineering
video Theo presented where they talk about some of this eating,
why they do it, and to what result.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Using TMPFS for /tmp and /var/run?

[grarpamp]

I commonly use mfs for /var and /tmp.
Sometimes even symlinking /var/tmp - /tmp to save ram.
Mostly because I want nothing leftover in them on boot, and it's fast.
rc/mtree/etc takes care of populating them.

/, /boot, /usr and /usr/local are read-only.
 [nssswitch host.conf still needs fixed to deal with that]
User and daemon writeables are on other mountpoints.
Thus I don't have any persistent needs in mfs.
No swap either. And cron is wiped out too.

No real problems. There used to be some msgs emitted about rc
populating it or rc being misordered using it. Those seem fixed.

mfs is a lot more stable than it used to be. In fact, the crashes
were what held me back till recently. Seems now I can hammer on
it with dd, fsx and iozone and it won't die.

Performance is fine whether under disk UFS+soft_updates or mfs.

The options below are fine for creating either. I don't care about
defaults... so long as both disk and ram options exist, I'm happy.
All depends on how you use it. I like nice clean separation. Some
(strange) people put everything in /. Oh well.

I'd rather see the legacy /sys and /compat symlinks removed.

rc_debug=YES
rc_info=YES

syslogd_flags=-sC

root_rw_mount=NO

tmpmfs_flags=-SM
tmpsize=64m
varmfs_flags=-SM
varsize=128m
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Burning CDs and DVDs on SATA drive in FreeBSD 9.0

[grarpamp]

In the past, I've used the ftp cdrtools pkg (made from the
port of course) and it failed to work. It's a popular tool so my
machine was probably out of sync. Same with burncd. However,
compiling the current cdrtools source worked fine. So I'd try
that first, compare, and send up a bug if need be.

Try to skip the scan by specifying the BTL or devpath on the
command line. The scan is a big part of the port and might
have breakage, at least for the app below.

Also, if you're doing audio, someone over on ports has said
they're doing an update to cdparanoia. It's minor, but useful
for that crowd.

makefs and burncd are part of the base, at least on RELENG_8.
And makefs is used in the official releases. So they should just work.

Good luck.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Third party apps in base [was CVS removal...]

[grarpamp]

Hi. I have many dependencies on CVS that I 'need' 'out of the box'.
Yet at the same time, I would not mind at all if it went to ports.
In fact, and from a general position regarding all third party apps,
I encourage it.

Mostly because they are not authored or maintained by FreeBSD. Yet
they are integrated, often in ways that need work to remove and/or
manage separately. Such as when the upstream drops a feature version
and FreeBSD only drops security/stability patches.

If a lighter method than ports is desired, all the third party apps
have binary packages (/pub/FreeBSD/ports/packages/All). And even
pkg_add can be skipped if that's too heavy. The bit of extra work
at install time isn't much, especially when your install already
does a bunch of scripted localization.

And as an aside, with what to this writer seems to be the majority
of the world moving to git... I think it should now properly become
user/admin choice as to which to install from ports/packages/source.
Rather than say, being equally agnostic/fair in the other direction
by including them all to satisfy all whims.

The only justified exception I see would be to include whichever
one is used by the master repository itself, which today is SVN.
And as a topic for another thread, I think even that should be
switched to git within the next couple years.

And as another topic for another thread... the same goes for the
various current methods of source (and other) distribution of the
FreeBSD project. I'd be quite happy to see rsync become authoritative
and even replace all of them.

Lastly, regarding baking and planning... making more use of the
wiki to document the FreeBSD timeline would be interesting. While
distant dates my not be known, features and dependancies usually are.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Jails: Setting different times in jails

[grarpamp]

 Why on earth would you want this?

Hi. Since your quote of my note was not to the original,
I'll repost it here. Kurt Lidl also posted useful situations
on these lists. Also, being able to have time tick backwards
in jails could be interesting fuzzing too :-) Enjoy.


Would be nice to be able to set different times in different jails.
All jails would tick in step with the system.
But each jail could have it's birthtime set specifically via jail(8),
jail(2), etc. Either by specification of a specific time, or an offset
from the current true system time. ie:

jail(8): -t [-|+]seconds

Child jails would offset from their parent, not the system.

Internally, gettimeofday, filesystem timestamps, and any other
userland interfaces would be hooked and adjusted by referencing
a table of jail ID's and their offsets. Similar to how setting TZ or
/etc/localtime effects a timezone offset. But transparent and
undetectable to the jail unless set as visible by the invoker.

Useful for creating alternate histories, testing time dependant
protocols and applications, forensics, pen testing, etc.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Jails: Setting different times in jails

[grarpamp]

 possibly achievable in libc?

I don't know. Where else would it be done?
stat, utimes, gettimeofday, clock_gettime,
adjtime, etc and their variations.

I've not checked what currently happens, but I
don't think root in a jail should be able to set
any kernel time parameters, absent a syscall
that says it should.

 in any case file this idea somewhere.. :-)

Don't know here either. I looked at the lists and
hackers seemed closest. I'll bcc current. Someone
could maybe todo-wiki this thread as low hanging
fruit. Cheers.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

FreeBSD Installer Roadmap

[grarpamp]

Sysinstall is fine, as I'm sure any replacement will be. So I'll
just note a few things I'd like to see in any such replacement...

1 - I used install.cfg's on floppies to clone systems, a lot. Hands
on the box were needed with that. Operators skills were in question,
so having them use the dialog menus properly was a pain and often
resulted in non-zeroed disk or half built systems. And though all
else was cloned, it needed a separate host.cfg for each box due
to:

fqdn, gateway, ip/mask
interface - sometimes changed
root disk - sometimes changed

Would have killed for a simple console shell script to ask those
questions of the operator, per machine.

2 - Being able to skip, replace, or prefix/suffix each stage of
whatever the installer would do with a shell script (ala: distSetCustom
local) would be cool.

3 - Options to dd if=/dev/zero of=/dev/[x] bs=1m, where x are any
boot sectors, drives, slices, partitions, labels, etc that would
otherwise be blown away but not fully wiped beforehand.


And a request for some remaining bugs to be fixed, implemented anew
or figured out...

1 - Setting debug=yes was great[a], up until you tried to get that
resultant file off the system or view it. Due to the way things
were mounted with mfsroot and the alt-f4 shell being separate, I
never did figure out how to do that.

[a] - only when calling /stand/sysinstall from your development box
to test your install.cfg, and the install process. Not when actually
installing a box.

2 - mediaClose - didn't work right. I couldn't get the base
distribution bits from one ftp server, and the local distribution
bits from another.


And in general, I'll cheer for whichever camps are doing...
As opposed to mfsroot, boot a stripped kernel, on real filesystem,
with init to shell to installer.
and installroot things from there.
Some sort of plaintext backend that can read a config.
Pluggable frontends, at minimum 80x25 console shell, then
dialog/web/xorg/whatever.
Network boot, retrieve config via net, etc.

It would be cool to have an 'installer build' config option set
available during buildworld too. Much like you can configure crunchgen
to customize the crunch, you could customize certain parts of how
you wanted the installer to work. Particularly for things that might
take up space, what it thinks are its first places to get input,
boot from, display, where to find its config while blind, etc.
And a stripped buildworld kernel config for use with the installer.
Call it just more permutations on the liveCD concept.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ZFS v15 patch (version 3)

[grarpamp]

Wanted to say thank you for those working on keeping ZFS up to date :-)

Are all the non-FreeBSD specific fixes being made by the FreeBSD team
being punted back up to the [Open]Solaris folks so that they may include
them in their native ZFS... and thus trickle back down to FreeBSD, thereby
minimizing the overall FreeBSD porting/review changeset?

Here is the ZFS site's list of the major version differences for reference.

Note that I think upwards resize and maybe one other commonly requested
item are actually present in one of these versions but didn't make it into
the log below, it's probably on zfs-discuss though.

[zpool v15, zfs v4] seems to be a good spot... till ZFS-crypto ;-)
Thanks!

http://hub.opensolaris.org/bin/view/Community+Group+zfs/n   [zpool]
http://hub.opensolaris.org/bin/view/Community+Group+zfs/n-1 [zfs]



ZFS File System Version 5

This version includes support for the following feature:

* System attributes

This feature is available in:

* Nevada, build 137

The related change requests are:

* 6716117 ZFS needs native system attribute infrastructure
* 6516171 zpl symlinks should have their own object type



ZFS File System Version 4

This version includes support for the following features:

* useru...@... and groupu...@... properties
* userqu...@... and groupqu...@... properties

These features are available in:

* Solaris Express Community Edition, build 114

The related bug and PSARC case for version 4 changes are:

* 6501037 want user/group quotas on ZFS
* PSARC 2009/204 ZFS user/group quotas  space accounting



ZFS File System Version 3

This version includes support for the following features:

* Support for sharing ZFS file systems over CIFS
* Case insensitivity support
* System attribute support
* Integrated anti-virus support

These features integrated into the following release:

* Solaris Express Community Edition, build 77

These features were integrated with the following bug fixes:

* 6617183 CIFS Service  PSARC 2006/715
* 6546893 Solaris system attribute support
* 6417428 Case-insensitive file system name lookup to support
CIFS
* 6417435 DOS attributes and additional timestamps to support
for CIFS
* 6417442 File system quarantined and modified attributes to
support an integrated Anti-Virus service



ZFS File System Version 2

This version includes support for the following features:

* Enhanced directory entries. In particular, directory entries
now store the object type, (for example, file, directory, named
pipe, and so on) in addition to the object number.

* Upgrading ZFS file systems to provide future ZFS file system
enhancements to existing file systems.

These features were integrated with the following bug fixes:

* 6572637 store object type in directory entries
* PSARC/2007/328 zfs upgrade

These features are available in:

* Solaris Express Community Edition, build 69



File System Version 1

This page describes the features that are available with version 1
of the ZFS file system on-disk format (not the pool version). Because
this is the initial ZFS on-disk format that integrated on 10/31/05,
see the list of initial features in the ZFS Admin Guide. The first
official releases supporting this version are:

* Solaris Express Community Edition, build 36
* Solaris 10 6/06 release




ZFS Pool Version 24

This version includes support for system attributes.

Pool version 24 is available in this release:

* Nevada, build 137

The change records for the version 24 change are:

* 6716117  ZFS needs native system attribute infrastructure
* 6516171  zpl symlinks should have their own object type



ZFS Pool Version 23

This version includes support for the slim ZIL.

Pool version 23 is available in this release:

* OpenSolaris, build 135

The change record for the version 23 change is:

* 6595532 ZIL is too talkative



ZFS Pool Version 22

This version includes support for zfs receive properties.

Pool version 22 is available in this release:

* Solaris Express Community Edition, build 128

The PSARC case for the version 22 change is:

* PSARC/2009/510 ZFS Received Properties



ZFS Pool Version 21

This version includes support for ZFS deduplication properties.

Pool version 21 is available in this release:

* Solaris Express Community Edition, build 128

The PSARC case for the version 21 change is:

* PSARC/2009/571 ZFS Deduplication Properties



ZFS Pool Version 20