Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
> I won't fail to defend general anti-nym opinion or guidance d-oh, s/defend/defend against/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
>> grarpamp >> the various good uses for nyms. > cpgh...@cordula.ws > I hope you realize whom you're trying to lecture here! > Joerg Wunsch is a highly appreciated long-time FreeBSD contributor Of course. No one here has any question as to anyone's FreeBSD participation. That would be silly :) I merely contest the suggestion that nyms have little to no utility, that people need moderate their usage alone in public, and that those using them are somehow lessers. I won't fail to defend general anti-nym opinion or guidance, particularly when wafted in this general direction. > Now, back to our regular programming. Yes, about this lack of a self-authenticating repo, etc. [1] It is good to see some discussion forming around it :) [1] Or whatever it may better be called. Put another way... we can't yet say, in the strong cryptographic sense, that anyone has a true copy of the repo. Or that the repo is itself internally tamper free and/or tamper proof. And so on as applied down the production and distribution chain. The repo does face certain risks. And Git appears as if it may be one way to mitigate them. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Sun, Nov 18, 2012 at 1:57 AM, Garrett Wollman wrote: >> the various good uses for nyms. > > There are no such uses on the FreeBSD mailing-lists; if you wish for > anyone to pay attention to you, then use a real name. Otherwise, > FOAD. > > -GAWollman It appears you have not reviewed the mailing list archives, otherwise you would have found many such nym holders engaging in good participation. However I do thank you for your opinion, and for your delightful and unwarranted private abuse. A good day to you indeed, Sir. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
http://www.freebsd.org/news/2012-compromise.html http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-security-breach-via-stolen-ssh-key This is not about this incident, but about why major opensource projects need to be using a repository that has traceable, verifiable, built-in cryptographic authentication. Any of hundreds of committer and admin accounts could be compromised with the attacker silently editing the repo. The same applies to any of those accounts going rogue. Backtrack diffing from a breach to 'see what changed' is not the ideal option. You really need to be using a strong repo so that any attack on it is null from the start. Another problem is bit rot wherever it may occur... disk, hardware, the wire, EMP and other systems. As it is now, we have no way to verify that what we get on pressed CD's, ISO's, FTP sites, torrents, etc is strongly linked back to the original repo. Signing over a hash of the ISO is *not* the same as including the strong repo hash (commit) that was used to build the release and then signing over that and the ISO. We can't know that our local repository updates match the master. ports.tar.gz has no authentication either. Nor does anything in the entire project that originates from the current SVN/CVS repo... webpages, docs, tools, source tarballs, etc. The FTP packages aren't signed, and there are weak MD5's used in various parts of the install/package tools, mirrors, etc. We can't trade hashes amongst people. It's all just a bunch of random bits that someone may or may not have signed over. And even if signed they still wouldn't be strongly linked back to the master repo. Having such a disconnect at the root of everything you do is simply not good practice these days. And these days, Git is what people and projects are moving to, and its rate of adoption and prevalence have essentially won out over all the rest in the new 'revision control 2.0 world'. And knowing Git is now more or less essential if you want to participate in a wide variety of community development, ref: github, etc. The FreeBSD project needs to be providing both itself, and its users and benefactors with verifiable assurance that its repository, and any copies and derived products, are authentic and intact. Don't argue against such a repository feature, or the cost to move, or bury your head in the sand by saying it could never happen to us... Take this as a real opportunity to lead amongst the major opensource projects like Linux, and among the BSD's (like DragonFly has), and move to Git. Once the root is fixed, you can push out secure distribution and update models from there. It all starts at the root and can't be done without it. https://www.kernel.org/pub/software/scm/git/docs/git-fsck.html Verifies the connectivity and validity of the objects in the database http://git-scm.com/about/info-assurance The data model that Git uses ensures the cryptographic integrity of every bit of your project. Every file and commit is checksummed and retrieved by its checksum when checked back out. It's impossible to get anything out of Git other than the exact bits you put in. It is also impossible to change any file, date, commit message, or any other data in a Git repository without changing the IDs of everything after it. This means that if you have a commit ID, you can be assured not only that your project is exactly the same as when it was committed, but that nothing in its history was changed. https://en.wikipedia.org/wiki/Git_(software) The Git history is stored in such a way that the id of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. The structure is similar to a hash tree, but with additional data at the nodes as well as the leaves. Some references... http://git-scm.com/ https://github.com/ http://gitweb.dragonflybsd.org/dragonfly.git https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Upcoming release schedule - 8.4 ?
Realized my earlier related post was a bit misplaced in questions@. So I just refer to it here by link, ok then that is all. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=968504+0+current/freebsd-questions ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Silicon Image programming docs
Found some datasheets (programming docs) and board schematics for Silicon Image storage controllers. Since they don't seem to be publicly available, perhaps some of these docs will be useful. Bcc'd relevant fs and hackers lists. Reply to hardware I guess. # Overview http://www.siliconimage.com/products/family.aspx?id=3 http://www.siliconimage.com/docs/Site_PDFs/Product_Guide_3Q_2011.pdf # SiI0680 http://www.siliconimage.com/docs/SiI-DS-0069-C.pdf http://www.siliconimage.com/docs/SiI-SC-0094-A.PDF # SiI3114 http://www.siliconimage.com/docs/SiI-DS-0103-D.pdf http://www.siliconimage.com/docs/SiI-SC-0057-B.PDF # SiI3124 http://www.siliconimage.com/docs/SiI-DS-0160-C.pdf http://www.siliconimage.com/docs/312404_B00_092704.PDF # SiI3132 http://www.siliconimage.com/docs/SiI-DS-0136-B.pdf http://www.siliconimage.com/docs/SiI-DS-0138-E.pdf http://www.siliconimage.com/docs/SiI-SC-0097_doc.pdf # SiI3512 http://www.siliconimage.com/docs/SiI-DS-0102-D.pdf http://www.siliconimage.com/docs/SiI-DS-0107-C.pdf http://www.siliconimage.com/docs/SiI-SC-0056-B.PDF # SiI3531 http://www.siliconimage.com/docs/SiI-DS-0208-C.pdf http://www.siliconimage.com/docs/SiI-SC-215.PDF # SiI3726 http://www.siliconimage.com/docs/FINAL%20SiI3726%20Product%20Brief_02-16-2011.pdf http://www.siliconimage.com/docs/SiI-DS-0121-C1.pdf # SiI3811 http://www.siliconimage.com/docs/SiI3811_PB58_FINAL_8-17-06.pdf http://www.siliconimage.com/docs/SiI-SC-0231-A.PDF ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Jails: Setting different times in jails
> 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 [-|+] 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Jails: Setting different times in jails
> 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Jails: Setting different times in jails
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 [-|+] 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD I/OAT (QuickData now?) driver [10gb pfring silicom]
Perhaps some similar work here. And maybe a card vendor with docs and an affinity to open source. Just news, that's all. http://www.ntop.org/blog/pf_ring/introducing-the-10-gbit-pf_ring-dna-driver/ bcc: hackers, isp. reply to net. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
FreeBSD I/OAT (QuickData now?) driver
Is this work part of what's needed to enable the FreeBSD equivalent of TNAPI? I know we've got polling. And probably MSI-X in a couple drivers. Pretty sure there is still one CPU doing the interrupt work? And none of the multiple queue thread spreading tech exists? http://www.ntop.org/blog http://www.ntop.org/TNAPI.html TNAPI attempts to solve the following problems: * Distribute the traffic across cores (i.e. the more core the more scalable is your networking application) for improving scalability. * Poll packets simultaneously from each RX queue (contraty to sequential NAPI polling) for fetching packets as fast as possible hence improve performance. * Through PF_RING, expose the RX queues to the userland so that the application can spawn one thread per queue hence avoid using semaphores at all. TNAPI achieves all this by starting one thread per RX queue. Received packets are then pushed to PF_RING (if available) or through the standard Linux stack. However in order to fully exploit this technology it is necessary to use PF_RING as it provides a straight packet path from kernel to userland. Furthermore it allows to create a virtual ethernet card per RX queue. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Why not give git a try?
Hi. This is good topic. I am no body. But I want to mention things. I've use RCS, CVS, SVN, Hg and Git. To me, first three are really much one in same. Of later two still learning, Hg can be slightly easier, but Git has simple analogs too, not much hard to get. We all learn new thing. But overall, Git seems to be on curve as the one become defacto for all good reasons/purpose in new world. Just as was CVS. Coders will know it. Gitweb, etc. So it momentum to maybe break ties, lame but can be true. I am ok with it. Distributed also maybe, maybe, save project bandwidth, as ppl tracking multiple branches should mirror and checkout locally. Not checkout multiple branch over wire. And can work fully local. Yes, maybe distrib not as much enforce commit from private coders often. But people already have those involved/not, regular/not, central/not habits, repo make no diff. Yet better, distrib enables some new good models not possible before too, while still letting some old style happen too. Also, very important this one. Git provide hash authenticated chained repo possibility by default and native with every commit from init of new repo. CVS/SVN do not do that. FreeBSD is big project (with big users). With big project infrastruct. With big group with commit people login from bfe from some fubar systems sometime unknown. All good ppl and systems yes, but deteching errors and provide proofs and chains is important now days in IT worlds. Too, FreeBSD only sign release cd's and only on maj.min release, not security branche, releng branche etc. There is no strong trace back to repo, so link is cut there. It is repo hash that should be sign, first before cd, and from there all things roll down as extra bonus. Does pictures on this important one be clear? And if move beyond CVS/SVN legacy wanted, yes?, start tests, eval, pick and move on :) My local stuffs went CVS to Git, but is no matter that choice to this project topic. I try agnostic. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
msdosfs exit status, failures: chmod, touch
This exit should not be 0, regardless of msdosfs or not. Same for if the '.' dir entries do in fact have B/M/A/C times, operations on those entries should update those times accordingly, as subdirs do. RELENG_8. Thanks. # newfs_msdos /dev/fd0 /dev/fd0: 2829 sectors in 2829 FAT12 clusters (512 bytes/cluster) BytesPerSec=512 SecPerClust=1 ResSectors=1 FATs=2 RootDirEnts=512 Sectors=2880 Media=0xf0 FATsecs=9 SecPerTrack=18 Heads=2 HiddenSecs=0 # mount_msdosfs /dev/fd0 /mnt # ls -alt /mnt total 18 drwxr-xr-x 22 root wheel512 Jun 8 17:00 .. drwxr-xr-x 1 root wheel 16384 Dec 31 1979 . # chmod 1777 /mnt ; echo $? 0 # touch /mnt ; echo $? 0 # ls -alt /mnt total 18 drwxr-xr-x 22 root wheel512 Jun 8 17:00 .. drwxr-xr-x 1 root wheel 16384 Dec 31 1979 . ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
vm: kvm_free max_wired
Is this telling me I should be able to set kmem_size to around 740MiB before the kernel panics during boot? Any runtime issues with doing that? # sysctl hw.physmem hw.realmem vm.kvm_size vm.kvm_free vm.kmem_size hw.physmem: 1055293440 hw.realmem: 1072627712 vm.kvm_size: 1073737728 vm.kvm_free: 205516800 vm.kmem_size: 536870912 # sysctl -d hw.physmem vm.kvm_size vm.kvm_free vm.kmem_size hw.physmem: hw.realmem: vm.kvm_size: Size of KVM vm.kvm_free: Amount of KVM free vm.kmem_size: Size of kernel memory This doesn't seem to autosize. Is that expected? Should one care about this sysctl? vm.max_wired: System-wide limit to wired page count vm.max_wired: 83211 83211*4096/2^20 = ~325 Also, these are obviously broken / curious: debug.boothowto: -2147481598 net.inet.tcp.inflight.max: 1073725440 Running RELENG_8. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
ZFS version list [was ETA for ZFS ver: n]
ZFS version list [was ETA for ZFS ver: n]
I needed raw, bit reliable, stable, encrypted storage. ZFS gave all
but the last part so far. None of the features since v6 were useful
to me. And as with most software, there are surely tons of fixes
and optimizations being handled silently that are useful.
Additions at or before v6 that were nifty:
compression
hot spares
raidz2
ditto blocks
sha256 - chained back to the uberblock thing
Integrated crypto will be very useful, simply to eliminate that
GEOM. Even if GBDE and GELI are cool :) Hopefully ZFS will include
a strong 256 bit cipher along with other options. My guess is that
it will be out from SUN midyear, before FBSD 8.0, and thus a potential
for 8.0.
The ZFS iSCSI bit might be cool. Putting things like that all under
the ZFS hierarchy could be sickly entertaining :)
If BSD chflags(2) schg, as on UFS, does or will work on ZFS, that's
cool. See the Solaris chmod command.
FBSD could very well have magically encrypted user homedirs that
make use of some of the inherent ZFS [delegation, etc?] features.
login could be hacked as could sshd or possibly pamify things.
Haven't really thought about it other than Apple has it. Don't know
about other BSD's.
It is awesome that FBSD has ZFS! No matter what gets done when,
thanks for all the work on it... past, present and on into future.
Version list attached for people to reference...
http://opensolaris.org/os/community/zfs/version//
ZFS Pool Version 14
This version includes support for the following feature:
* passthrough-x aclinherit property support
This feature is available in:
* Solaris Express Community Edition, build 103
The related bug and PSARC case for the version 14 change are:
* 6765166 Need to provide mechanism to optionally inherit
ACE_EXECUTE
* PSARC 2008/659 New ZFS "passthrough-x" ACL inheritance rules
ZFS Pool Version 13
This version includes support for the following features:
* usedbysnapshots property
* usedbychildren property
* usedbyrefreservation property
* usedbydataset property
These features are available in:
* Solaris Express Community Edition, build 98
The related bug and PSARC case for version 13 change is:
* 6730799 want snapused property
* PSARC 2008/518 ZFS space accounting enhancements
ZFS Pool Version 12
This version includes support for the following feature:
* Properties for Snapshots
This feature is available in:
* Solaris Express Community Edition, build 96
The related bug for the version 12 change is:
* 6701797 want user properties on snapshots
ZFS Pool Version 11
This version includes support for the following feature:
* Improved zpool scrub / resilver performance
This feature is available in:
* Solaris Express Community Edition, build 94
The related bug for the version 11 change is:
* 6343667 scrub/resilver has to start over when a snapshot is
taken
* (Note, this bug is fixed when using build 94 even with older
pool versions. However, upgrading the pool can improve scrub
performance when there are many filesystems, snapshots, and
clones.)
ZFS Pool Version 10
This version includes support for the following feature:
* Devices can be added to a storage pool as "cache devices."
These devices provide an additional layer of caching between
main memory and disk. Using cache devices provides the greatest
performance improvement for random read-workloads of mostly
static content.
This feature is available in the Solaris Express Community Edition,
build 78.
The Solaris 10 10/08 release includes ZFS pool version 10, but
support for cache devices is not included in this Solaris release.
The related bug for the version 10 change is:
* 6536054 second tier ("external") ARC
ZFS Pool Version 9
This version includes support for the following features:
* In addition to the existing ZFS quota and reservation features,
this release includes dataset quotas and reservations that do
not include descendent datasets, such as snapshots and clones,
in the space consumption. ("zfs set refquota" and "zfs set
refreservation".)
* A reservation is automatically set when a non-sparse ZFS
volume is created that matches the size of the volume. This
release provides an immediate reservation feature so that you
set a reservation on a non-sparse volume with enough space to
take snapshots and modify the contents of the volume.
* CIFS server support
These features are available in Solaris Express Community Edition,
build 77.
The related bugs for version 9 changes are:
* 6431277 want filesystem-only quotas
* 6483677 n
