Re: [9fans] problems with tracing 9vx on os x (was: Re: ghostscript not finding LucidaSans
2010/6/28 Pietro Gagliardi : > First I found a slight building problem on Mac OS X 10.5.8: ethertap.c needs > to be changed to include before and to add a > defined(__MACOSX__) or similar to the #elf defined(__FreeBSD__) so opentap() > can be defined. > > However once this version was built, I got the following right after seeing > the memory usage statistic line: ethertap is part of the modifications I'm doing to 9vx as part of my gsoc project. Since I don't have any machine running OS X, the darwin version is far behind the linux one. I compile 9vx in FreeBSD from time to time, but running it is another history. Eventually I'd like to do something about this. For the time being, you can fill an issue at http://bitbucket.org/yiyus/vx32/ or, even better, send me a patch. By the way, you should be able to deactivate compilation of the tap (or pcap) ether device with the variable PLAN9TAP (PLAN9PCAP) in Makefrag. -- - yiyus || JGL . 4l77.com
Re: [9fans] offered without comment or judgement
On Mon, Jun 28, 2010 at 3:32 PM, ron minnich wrote: > not saying it is "good" or "bad", just wanted people to see it > > > https://www.signup4.net/UPLOAD/STRA10A/DARP31E/CRASH%20Proposer%20Day%20v2.pdf Perhaps I am oversimplifying, but the proposed resolution seems to be: Abstract MINIX. Best, ak
Re: [9fans] offered without comment or judgement
> not saying it is "good" or "bad", just wanted people to see it So is it now "bad" to say what you think? If you live in a hostile environment, with rules too complex to understand, it's clever to be also unpredictable. Computer networks are different. Discrete electronics haven't been invented to create entropy...
Re: [9fans] offered without comment or judgement
> Computer networks are different. Discrete electronics haven't been > invented to create entropy... my air conditioner begs to differ! - erik
Re: [9fans] offered without comment or judgement
hello I do like their aim, let's see what they end with :), if that's disclosed someday. . . :), also seems they will end with something too complex to be of general usage slds. gabi - Original Message From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Sent: Tue, June 29, 2010 12:32:29 AM Subject: [9fans] offered without comment or judgement not saying it is "good" or "bad", just wanted people to see it https://www.signup4.net/UPLOAD/STRA10A/DARP31E/CRASH%20Proposer%20Day%20v2.pdf ron
[9fans] interesting pci configuration
i hadn't seen bussno > 15 before. might as well go for broke: [...] 2.4.0: net 02.00.00 14e4/16aa 7 0:f804 33554432 1: 16 64.15.0:brg 06.04.00 1166/0140 11 64.16.0:brg 06.04.00 1166/0142 7 64.17.0:brg 06.04.00 1166/0144 11 64.18.0:brg 06.04.00 1166/0142 11 64.19.0:brg 06.04.00 1166/0144 11 65.0.0: net 02.00.00 8086/10d9 11 0:fdce 131072 1:fdc0 524288 2:4001 32 65.0.1: net 02.00.00 8086/10d9 11 0:fdbe 131072 1:fdb0 524288 2:4021 32 72.0.0: net 02.00.00 8086/10d9 7 0:fdee 131072 1:fde0 524288 2:5001 32 72.0.1: net 02.00.00 8086/10d9 11 0:fdde 131072 1:fdd0 524288 2:5021 32 79.0.0: brg 06.04.00 1166/0103 96 80.4.0: brg 06.04.00 1166/0104 255 80.8.0: disk 01.04.00 103c/3238 11 0:fdf80004 524288 1: 16 2:6001 256 3:fdf7 32768 - erik
Re: [9fans] problems with tracing 9vx on os x (was: Re: ghostscript not finding LucidaSans
On Jun 29, 2010, at 4:03 AM, yy wrote: By the way, you should be able to deactivate compilation of the tap (or pcap) ether device with the variable PLAN9TAP (PLAN9PCAP) in Makefrag. Okay, I did so but I still get the crash as before. Here's a gdb backtrace: #0 0x919366fa in select$DARWIN_EXTSN () #1 0xfc75 in microdelay (x=100) at 9vx/time.c:389 #2 0xdb9c in dt_panic (fmt=0xbd5cc "user fault: signo=%d addr=%p [useraddr=%p] read=%d eip=%p esp=%p") at 9vx/stub.c:536 #3 0xa886 in sigsegv (signo=10, info=0x5e1fc0, v=0x5e1d20) at 9vx/ main.c:844 #4 0x00013b5c in wrapper (siginfo=0x5e1fc0, mcontext=0x5e1d60, handler=0xa769 ) at 9vx/osx/signal.c:85 #5 0x000b6e09 in xscan (p=0x63f3a0) at libvx32/emu.c:247 #6 0x000b9bda in xlate (vxp=0x63f3a0) at libvx32/emu.c:1695 #7 0x000b9e7e in vxproc_run (vxp=0x63f3a0) at libvx32/emu.c:1841 #8 0x0001373f in touser (initsp=0xfa4) at 9vx/vx32.c:251 #9 0xa762 in init0 () at 9vx/main.c:742 I'm not sure what this information would give you, but...
Re: [9fans] offered without comment or judgement
To me it seems that their aim is complexity. On 6/29/10, Gabriel Díaz wrote: > hello > > > I do like their aim, let's see what they end with :), if that's disclosed > someday. . . :), > also seems they will end with something too complex to be of general usage > > slds. > > gabi > > > > - Original Message > From: ron minnich > To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> > Sent: Tue, June 29, 2010 12:32:29 AM > Subject: [9fans] offered without comment or judgement > > not saying it is "good" or "bad", just wanted people to see it > > > https://www.signup4.net/UPLOAD/STRA10A/DARP31E/CRASH%20Proposer%20Day%20v2.pdf > > > ron > >
Re: [9fans] offered without comment or judgement
Stanley Lieber wrote: Anywhere legitimate identification is used, legitimate identification can be purchased. There are imperfect but very good ways to protect against that vulnerability. They vary with the needs (and budgets) of relying parties. -- Learn about The Authenticity Economy at http://video.google.com/videoplay?docid=-1419344994607129684&hl=en#
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
On Mon, Jun 28, 2010 at 3:03 PM, Eric Van Hensbergen wrote: > On Sat, Jun 26, 2010 at 4:26 AM, wrote: >>> but I can dig >>> them up, clean them up, and share them, >> >> My particular concern is to encourage convergence towards a single >> source distribution rather than divergence as seems to have been the >> case so far with Plan 9 native, Inferno, p9p and now Go. What I have >> chosen to do, ill-advised as it may be, is to set up a mercurial >> repository to re-distribute hacked Go sources that mostly contain >> harmless changes that make it possible to compile the Go sources and >> specifically the development toolchain with the Plan 9 toolchain. I'm >> presently trying to bring the work I did last year into this >> repository and at the same time keep track of the Go release. >> > > I've had a composite repo of previous attempts (well, Sape's previous > attempt) at doing this (for some time) at: > http://code.google.com/p/go-plan9/ > > I'm happy to add anyone to the committer/admin list, although my > preference is to keep the main branch in sync with go and have folks > attempts at conversion in sub-branches. You are of course welcome to > maintain your own repo with your own effort, I just figured if > everyone had a common place to see what approaches people were using > we might get there faster > > -eric Is the porting process active? -rob
Re: [9fans] offered without comment or judgement
2010/6/29 Wes Kussmaul : > Stanley Lieber wrote: >> >> Anywhere legitimate identification is used, legitimate identification can >> be purchased. > > There are imperfect but very good ways to protect against that > vulnerability. They vary with the needs (and budgets) of relying parties. I'm pretty sure you can't solve the problem. At the end of the day, it boils down to client-side security and what a person is willing to defend with their life. It's perfectly feasible to assume that identity information in a PKI world can be coerced and stolen as easily as physical identity information such as drivers licenses and social security cards. The security always breaks down at the personal level, and most private individuals aren't willing to die to protect this information. But you can do at least as good as these forms of ID. PKI requires knowledge of some sort of passkey. (I just worry about identification for people who are not smart enough to pick a good key. Which, unfortunately, is also most people. --dho
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
2010/6/29 Rob Pike : > On Mon, Jun 28, 2010 at 3:03 PM, Eric Van Hensbergen wrote: >> On Sat, Jun 26, 2010 at 4:26 AM, wrote: but I can dig them up, clean them up, and share them, >>> >>> My particular concern is to encourage convergence towards a single >>> source distribution rather than divergence as seems to have been the >>> case so far with Plan 9 native, Inferno, p9p and now Go. What I have >>> chosen to do, ill-advised as it may be, is to set up a mercurial >>> repository to re-distribute hacked Go sources that mostly contain >>> harmless changes that make it possible to compile the Go sources and >>> specifically the development toolchain with the Plan 9 toolchain. I'm >>> presently trying to bring the work I did last year into this >>> repository and at the same time keep track of the Go release. >>> >> >> I've had a composite repo of previous attempts (well, Sape's previous >> attempt) at doing this (for some time) at: >> http://code.google.com/p/go-plan9/ >> >> I'm happy to add anyone to the committer/admin list, although my >> preference is to keep the main branch in sync with go and have folks >> attempts at conversion in sub-branches. You are of course welcome to >> maintain your own repo with your own effort, I just figured if >> everyone had a common place to see what approaches people were using >> we might get there faster >> >> -eric > > Is the porting process active? I haven't had time, but have made promises. I'll start tonight. --dho > -rob > >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
Which things are yet to be done to get the port done?
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
FTS, I'm interesting in getting Go here because I'm going to write the i.e. window system (successor of o/live, o/mero, ...) also in go, to run at least the viewer native on unix systems. The C version is still cooking. On Tue, Jun 29, 2010 at 7:36 PM, Francisco J Ballesteros wrote: > Which things are yet to be done to get the port done? >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
On Tue, Jun 29, 2010 at 9:48 AM, Francisco J Ballesteros wrote: > FTS, I'm interesting in getting Go here because I'm going to write > the i.e. window system (successor of o/live, o/mero, ...) also in go, to run > at least the viewer native on unix systems. The C version is still cooking. Is there an overview/paper/etc. for i.e?
[9fans] i.e. (was go toolchain)
no yet. I'll post here when there's something to see. Sorry to polute the go thread with this, hence the new subject. On Tue, Jun 29, 2010 at 8:02 PM, Jack Johnson wrote: > On Tue, Jun 29, 2010 at 9:48 AM, Francisco J Ballesteros > wrote: >> FTS, I'm interesting in getting Go here because I'm going to write >> the i.e. window system (successor of o/live, o/mero, ...) also in go, to run >> at least the viewer native on unix systems. The C version is still cooking. > > Is there an overview/paper/etc. for i.e? > >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
> > Is the porting process active? > It seems to be an opportunistic concurrent activity (which is why I tried to create a central repo so we'd get some benefit from the sparse multiple activities). Most people were just waiting for Andrey :) There is some stuff that Forysth/Jmk have been looking at to allow for the segment registers, but Russ had suggested workaround at USENIX that I don't think anyone has had time to try yet. So here's what my take on what needs to be done: a) Simple logistics (makefile/script transformations, Sape's branch has some of this, what the right way to do this in order to be integrated back into the mainline go tree is an open question) b) support or workaround for the segment register stuff c) runtime support People seem to be mostly getting hung up on (a), (b) is probably the trickiest bit, and I think (c) is just a matter of sitting down and getting it done. I wonder if one way of avoiding (a) is just to rig to cross-compile from Linux/MacOSX to Plan 9 and get (b) and (c) done first then work back to (a), just because it seems like it would be more satisfying. -eric
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
Anyone (Russ?) can repeat here aprox. what the workaround for b was, for those like me that didn't attend usenix? On Tue, Jun 29, 2010 at 8:10 PM, Eric Van Hensbergen wrote: >> >> Is the porting process active? >> > > It seems to be an opportunistic concurrent activity (which is why I > tried to create a central repo so we'd get some benefit from the > sparse multiple activities). Most people were just waiting for Andrey > :) > > There is some stuff that Forysth/Jmk have been looking at to allow for > the segment registers, but Russ had suggested workaround at USENIX > that I don't think anyone has had time to try yet. > > So here's what my take on what needs to be done: > > a) Simple logistics (makefile/script transformations, Sape's branch > has some of this, what the right way to do this in order to be > integrated back into the mainline go tree is an open question) > b) support or workaround for the segment register stuff > c) runtime support > > People seem to be mostly getting hung up on (a), (b) is probably the > trickiest bit, and I think (c) is just a matter of sitting down and > getting it done. > > I wonder if one way of avoiding (a) is just to rig to cross-compile > from Linux/MacOSX to Plan 9 and get (b) and (c) done first then work > back to (a), just because it seems like it would be more satisfying. > > -eric > >
Re: [9fans] i.e. (was go toolchain)
Now that I remember, we recently added some demos for o/live & octopus to the http://lsub.org/ls/demos.html page and we didn't post here to let 9fans know. On Tue, Jun 29, 2010 at 8:04 PM, Francisco J Ballesteros wrote: > no yet. > I'll post here when there's something to see. > > Sorry to polute the go thread with this, hence the new subject. > > On Tue, Jun 29, 2010 at 8:02 PM, Jack Johnson wrote: >> On Tue, Jun 29, 2010 at 9:48 AM, Francisco J Ballesteros >> wrote: >>> FTS, I'm interesting in getting Go here because I'm going to write >>> the i.e. window system (successor of o/live, o/mero, ...) also in go, to run >>> at least the viewer native on unix systems. The C version is still cooking. >> >> Is there an overview/paper/etc. for i.e? >> >> >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
> a) Simple logistics (makefile/script transformations, Sape's branch > has some of this, what the right way to do this in order to be > integrated back into the mainline go tree is an open question) [...] > > I wonder if one way of avoiding (a) is just to rig to cross-compile > from Linux/MacOSX to Plan 9 and get (b) and (c) done first then work > back to (a), just because it seems like it would be more satisfying. i found that (a) wasn't hard. i got everything compiled rather quickly, but something came up before i could get going on the runtime. - erik
Re: [9fans] offered without comment or judgement
> But you can do at least as good as these forms of ID. PKI requires > knowledge of some sort of passkey. (I just worry about identification > for people who are not smart enough to pick a good key. Which, > unfortunately, is also most people. My understanding is a passkey just needs sufficent entropy in order to be strong. This can be a few characters drawn from a larger characterset - your password must be no more than 16 chars and must contain upper and lower case numbers and punctuation. Alternatively it could be a long string made up of a restricted character set - your pass phrase can consist of any text characters but must not contain long repitations and be of at least 200 characters long (say). Thus a passphrase may be a quote from your favorite movie, a lyric or the like. This can then be hashed into a higher entropy string (is this statement true?) used for authentication. I don't understand why modern security systems have an upper limit on passphrase length. (waits for people who know better to tell him he is dumb). -Steve
Re: [9fans] offered without comment or judgement
2010/6/29 Steve Simon : >> But you can do at least as good as these forms of ID. PKI requires >> knowledge of some sort of passkey. (I just worry about identification >> for people who are not smart enough to pick a good key. Which, >> unfortunately, is also most people. > > My understanding is a passkey just needs sufficent entropy in order to be > strong. Sure. But you can still brute-force a 4-character passkey in a reasonably short time. > This can be a few characters drawn from a larger characterset - your password > must > be no more than 16 chars and must contain upper and lower case numbers and > punctuation. > > Alternatively it could be a long string made up of a restricted character set > - your > pass phrase can consist of any text characters but must not contain long > repitations > and be of at least 200 characters long (say). This works, but tends to be easy to get out of people or figure out about people if you know a bit about them. > Thus a passphrase may be a quote from your favorite movie, a lyric or the > like. This > can then be hashed into a higher entropy string (is this statement true?) > used for > authentication. > > I don't understand why modern security systems have an upper limit on > passphrase length. Because people can't remember passwords, and companies don't like employing full-time password changers. --dho > (waits for people who know better to tell him he is dumb). > > -Steve > >
Re: [9fans] offered without comment or judgement
> > I don't understand why modern security systems have an upper limit on > > passphrase length. > > Because people can't remember passwords, and companies don't like > employing full-time password changers. i don't understand this comment. the length of a password is only vaguely related to memorability. long english phrases are easy to remember. unfortunately, they are also easy to harvest automaticly, so "four score and seven years ago" might be a bad password. - erik
Re: [9fans] offered without comment or judgement
2010/6/29 erik quanstrom : >> > I don't understand why modern security systems have an upper limit on >> > passphrase length. >> >> Because people can't remember passwords, and companies don't like >> employing full-time password changers. > > i don't understand this comment. the length of a password > is only vaguely related to memorability. long english phrases > are easy to remember. unfortunately, they are also easy to > harvest automaticly, so "four score and seven years ago" might > be a bad password. The problem is two-fold: a) Lay-people are told by all their "computer guru" friends to choose a password that is difficult to guess. Add numbers, capital letters, punctuation. Most people don't think in this sort of context, and it is difficult to remember. b) People don't regard the idea as particularly important. I know many people who routinely forget 6-8 character passwords. The length of the phrase is actually in fact tied explicitly to memory. The longer a string of characters, the more difficult it is to remember. That's just fact. You have to practice to recite a monologue; most people can't just read it once and commit it to memory. In a similar fashion, most people must either write down a password (which is dumb) or recite it for a fairly lengthy period of time to remember it. Noting that places having an upper bound on password length usually also have other password policies (like "must contain at least one of each: capital letter, lowercase letter, and number"). This either means things like initials and important dates (birthdays, anniversaries, etc) or random gibberish. People are told not to use something that can be socially engineered, so random gibberish it is. And people at large just don't get it. It's easily forgettable. When talking about symmetric cryptography, "four score and seven years ago" would probably be a great key. There is no convenient rainbow table upon which to do a hash lookup. It's sufficiently expensive to brute-force. The only thing that would give you any sort of advantage is knowing it was an english phrase and trying all of them. Misspellings, punctuation, capitalization, and the like can all throw this off. So picking something directly out of song lyrics, quotes, or a book of idioms is likely to be useless. Adding in a single period, comma, or some creative capitalization is fantastic. But we all know about passwords here. --dho > - erik > >
Re: [9fans] offered without comment or judgement
Devon H. O'Dell wrote: 2010/6/29 Wes Kussmaul : Stanley Lieber wrote: Anywhere legitimate identification is used, legitimate identification can be purchased. There are imperfect but very good ways to protect against that vulnerability. They vary with the needs (and budgets) of relying parties. I'm pretty sure you can't solve the problem. At the end of the day, it boils down to client-side security and what a person is willing to defend with their life. It's perfectly feasible to assume that identity information in a PKI world can be coerced and stolen as easily as physical identity information such as drivers licenses and social security cards. The security always breaks down at the personal level, and most private individuals aren't willing to die to protect this information. But you can do at least as good as these forms of ID. PKI requires knowledge of some sort of passkey. (I just worry about identification for people who are not smart enough to pick a good key. Which, unfortunately, is also most people It's true, people give up their ATM card PINs at gunpoint. Guns are a problem, especially where people tend to still use currency. Online, not so much. Possession is still the most effective factor. As our site points out, After spending millions of dollars on network security, corporations still have major security problems. Meanwhile, your ATM card allows your bank to dispense cash with confidence from a machine on a city sidewalk. The technology used by your ATM card is more ancient than the floppy disk. So why are bank ATM networks generally secure, while corporate information networks, in spite of continuous investment in the latest security technology, are barely able to keep ahead of intruders? The difference is not about technology. The difference is about assumptions and architecture. Your bank's ATM network starts with the premise that knowing who you are is the foundation of security. If a trusted co-worker asked you to share your ATM card and associated PIN, what would you say? Of course, they would never ask in the first place. If that co-worker asked you for your network password, what would you say? In many companies, collaborative work gets done by sharing access credentials, in spite of rules against it. -- Learn about The Authenticity Economy at http://video.google.com/videoplay?docid=-1419344994607129684&hl=en#
Re: [9fans] offered without comment or judgement
> The length of the phrase is actually in fact tied explicitly to > memory. The longer a string of characters, the more difficult it is to > remember. That's just fact repeating this doesn't make it true, but it does make the phrase easier to remember. so i think your argument is its own defeat. the gettysburg address is fairly easy for me to remember. but i don't think i'd have such an easy time on a randomly-choosen 285-word phrase. clearly something this long is not necessary. i'm sure you have made-up phrases with non-words you tell our dog. that should be easy to remember, not on the internet, and have the added bonus that you get to smile while typing your password. > When talking about symmetric cryptography, "four score and seven years > ago" would probably be a great key. There is no convenient rainbow > table upon which to do a hash lookup. It's sufficiently expensive to > brute-force. i'm not convinced of this. here's why. i was reading yesterday about a research-project that built a machine that could try 1 billion rsa keys/sec. now consider such a machine in the possession of bad guys. for them it would make sense to harvest nearly every phrase you can find on the internet and try it. the hard part would be crawling the net. - erik
Re: [9fans] i.e. (was go toolchain)
On Tue, Jun 29, 2010 at 11:26 AM, Francisco J Ballesteros wrote: > Now that I remember, we recently added some demos for > o/live & octopus to the http://lsub.org/ls/demos.html > page and we didn't post here to let 9fans know. > Thanks, this is very cool. I'm considering setting up a PC at my office, and a PC at home, and then terminals on each to the other, but I'm not sure if that's necessary or if the two PCs would suffice. Also should this be working on Snow Leopard? I'm having some difficulty but not sure where I'm making mistakes. Dave > > On Tue, Jun 29, 2010 at 8:04 PM, Francisco J Ballesteros > wrote: > > no yet. > > I'll post here when there's something to see. > > > > Sorry to polute the go thread with this, hence the new subject. > > > > On Tue, Jun 29, 2010 at 8:02 PM, Jack Johnson > wrote: > >> On Tue, Jun 29, 2010 at 9:48 AM, Francisco J Ballesteros > wrote: > >>> FTS, I'm interesting in getting Go here because I'm going to write > >>> the i.e. window system (successor of o/live, o/mero, ...) also in go, > to run > >>> at least the viewer native on unix systems. The C version is still > cooking. > >> > >> Is there an overview/paper/etc. for i.e? > >> > >> > > > >
Re: [9fans] i.e. (was go toolchain)
If you have problems we can try to help you off list. On Tue, Jun 29, 2010 at 9:30 PM, David Leimbach wrote: > > > On Tue, Jun 29, 2010 at 11:26 AM, Francisco J Ballesteros > wrote: >> >> Now that I remember, we recently added some demos for >> o/live & octopus to the http://lsub.org/ls/demos.html >> page and we didn't post here to let 9fans know. > > Thanks, this is very cool. I'm considering setting up a PC at my office, and > a PC at home, and then terminals on each to the other, but I'm not sure if > that's necessary or if the two PCs would suffice. > Also should this be working on Snow Leopard? I'm having some difficulty but > not sure where I'm making mistakes. > Dave > >> >> On Tue, Jun 29, 2010 at 8:04 PM, Francisco J Ballesteros >> wrote: >> > no yet. >> > I'll post here when there's something to see. >> > >> > Sorry to polute the go thread with this, hence the new subject. >> > >> > On Tue, Jun 29, 2010 at 8:02 PM, Jack Johnson >> > wrote: >> >> On Tue, Jun 29, 2010 at 9:48 AM, Francisco J Ballesteros >> >> wrote: >> >>> FTS, I'm interesting in getting Go here because I'm going to write >> >>> the i.e. window system (successor of o/live, o/mero, ...) also in go, >> >>> to run >> >>> at least the viewer native on unix systems. The C version is still >> >>> cooking. >> >> >> >> Is there an overview/paper/etc. for i.e? >> >> >> >> >> > >> > >
Re: [9fans] offered without comment or judgement
2010/6/29 erik quanstrom : >> The length of the phrase is actually in fact tied explicitly to >> memory. The longer a string of characters, the more difficult it is to >> remember. That's just fact > > repeating this doesn't make it true, but it does make > the phrase easier to remember. so i think your argument > is its own defeat. the gettysburg address is fairly easy for > me to remember. but i don't think i'd have such an easy > time on a randomly-choosen 285-word phrase. > > clearly something this long is not necessary. i'm sure you > have made-up phrases with non-words you tell our dog. > that should be easy to remember, not on the internet, and > have the added bonus that you get to smile while typing your > password. You're taking this slightly out of context. I said that this is coupled with the fact that peers encourage the use of randomness in a password, and companies enforce password policies that corroborate this need. I'm not suggesting there's a set length at which point people have difficulty remembering something, but there is certainly a correlation: you certainly aren't going to argue the chances of remembering "fsd&e" are much greater than remembering "amsdagk3881((@!3ll1..dags8" are you? Similarly, you wouldn't argue that at some point you spent time learning the Gettysburg Address -- it's not simply something you read once and recalled. (If so, this is impressive, and you shouldn't argue this as "normal".) Length of the phrase is certainly tied to the ability to commit it to memory. Yes, I'm repeating this using empirical evidence as I'm slightly too lazy to go look up any of the several articles I've read about how we memorize things and how "brain storage" actually works. There are ways to bypass this to some degree: adding music or tune, creating rhyme, setting to iambic pentameter (or any "rhythmization" for that matter). As computing systems continue to get stronger, the necessity of longer passphrases will increase -- or slower secure algorithms will need to be developed. (Or possibly more fitting algorithms, given the possibility of quantum computing, which may intrinsically provide solutions to some implementation issues following PKI). >> When talking about symmetric cryptography, "four score and seven years >> ago" would probably be a great key. There is no convenient rainbow >> table upon which to do a hash lookup. It's sufficiently expensive to >> brute-force. > > i'm not convinced of this. here's why. i was reading yesterday > about a research-project that built a machine that could try 1 billion > rsa keys/sec. now consider such a machine in the possession of bad > guys. for them it would make sense to harvest nearly every phrase > you can find on the internet and try it. the hard part would be > crawling the net. I certainly have several nonsensical words / names for my cats. None of them contain numbers or punctuation or anything associated with a strong passphrase. The longest of these is probably about 12 characters. And a system that can try a billion RSA keys per second is going to quickly exhaust the relatively short combination of these, even brute forcing. And you're right -- as I also alluded above, the continued computing and mathematical advancements made by society at large will continue to obsolete any statements about what a "good pass phrase" is. Right now, it's length and perceived randomness. People have enough difficulty remembering short passwords. Or creating "good" passwords in the first place. Upper bounds along with enforcing permutations are placed to reduce peoples' likelihood of forgetting them while still providing some level of security. It's not the best approach, but until people start treating passwords like an ATM card with a PIN, it's not going to matter much anyway. (Ignoring that PINs for most cards are only have 9990 or fewer permutations.) --dho > - erik > >
Re: [9fans] offered without comment or judgement
Devon H. O'Dell wrote: 2010/6/29 erik quanstrom : I don't understand why modern security systems have an upper limit on passphrase length. Because people can't remember passwords, and companies don't like employing full-time password changers. i don't understand this comment. the length of a password is only vaguely related to memorability. long english phrases are easy to remember. unfortunately, they are also easy to harvest automaticly, so "four score and seven years ago" might be a bad password. The problem is two-fold: a) Lay-people are told by all their "computer guru" friends to choose a password that is difficult to guess. Add numbers, capital letters, punctuation. Most people don't think in this sort of context, and it is difficult to remember. b) People don't regard the idea as particularly important. I know many people who routinely forget 6-8 character passwords. Many banks still use 4 digit PINs on their ATM cards, without problem. Possession is a very important factor. The token that will prevail of course is the phone - even though it denies relying parties the billboard value of a card. Now, will developers be smart enough to isolate the private key from the phone's porous OS? The jury is out on that. wk -- Learn about The Authenticity Economy at http://video.google.com/videoplay?docid=-1419344994607129684&hl=en#
Re: [9fans] offered without comment or judgement
On Tue, Jun 29, 2010 at 2:14 AM, hiro <23h...@googlemail.com> wrote: >> not saying it is "good" or "bad", just wanted people to see it > > So is it now "bad" to say what you think? Nope, I just have my own opinions on this but don't want to corrupt anyone :-) ron
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
I was sleep-deprived much of the week, so my memory is most likely not exact (so hopefully Russ will provide a clarification), but I believe he said something along the lines of pointing to the top of the stack as a workaround. I haven't had a chance to look at it yet, so that's about as much of a hint as I can give at the moment. -eric On Tue, Jun 29, 2010 at 1:12 PM, Francisco J Ballesteros wrote: > Anyone (Russ?) can repeat here aprox. what the workaround for b was, for > those like me that didn't attend usenix? > > On Tue, Jun 29, 2010 at 8:10 PM, Eric Van Hensbergen wrote: >>> >>> Is the porting process active? >>> >> >> It seems to be an opportunistic concurrent activity (which is why I >> tried to create a central repo so we'd get some benefit from the >> sparse multiple activities). Most people were just waiting for Andrey >> :) >> >> There is some stuff that Forysth/Jmk have been looking at to allow for >> the segment registers, but Russ had suggested workaround at USENIX >> that I don't think anyone has had time to try yet. >> >> So here's what my take on what needs to be done: >> >> a) Simple logistics (makefile/script transformations, Sape's branch >> has some of this, what the right way to do this in order to be >> integrated back into the mainline go tree is an open question) >> b) support or workaround for the segment register stuff >> c) runtime support >> >> People seem to be mostly getting hung up on (a), (b) is probably the >> trickiest bit, and I think (c) is just a matter of sitting down and >> getting it done. >> >> I wonder if one way of avoiding (a) is just to rig to cross-compile >> from Linux/MacOSX to Plan 9 and get (b) and (c) done first then work >> back to (a), just because it seems like it would be more satisfying. >> >> -eric >> >> > >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
erik's attempt is now in the go-plan9 repo under its own branch for those that wish to take a look. Hopefully I merged it properly. -eric On Tue, Jun 29, 2010 at 1:32 PM, erik quanstrom wrote: >> a) Simple logistics (makefile/script transformations, Sape's branch >> has some of this, what the right way to do this in order to be >> integrated back into the mainline go tree is an open question) > [...] >> >> I wonder if one way of avoiding (a) is just to rig to cross-compile >> from Linux/MacOSX to Plan 9 and get (b) and (c) done first then work >> back to (a), just because it seems like it would be more satisfying. > > i found that (a) wasn't hard. i got everything compiled > rather quickly, but something came up before i could get > going on the runtime. > > - erik > >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
On Tue Jun 29 16:46:40 EDT 2010, eri...@gmail.com wrote: > erik's attempt is now in the go-plan9 repo under its own branch for > those that wish to take a look. > Hopefully I merged it properly. it compiles and links, but obviously doesn't run since there really is no runtime. - erik
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
Can someone remind me of the problem? Is it simply the need to be able to set %gs? Could a write to /dev/arch of something like gs 0xwhatever which sets %gs for that process solve the problem? Or is it bigger than that? ron
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
2010/6/29 erik quanstrom : > On Tue Jun 29 16:46:40 EDT 2010, eri...@gmail.com wrote: >> erik's attempt is now in the go-plan9 repo under its own branch for >> those that wish to take a look. >> Hopefully I merged it properly. > > it compiles and links, but obviously doesn't run > since there really is no runtime. Or syscall implementation or net / fd / etc implementation. pkg/runtime should be easy. I'll do it tonight. --dho > - erik > >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
On Tue, Jun 29, 2010 at 2:15 PM, Devon H. O'Dell wrote: > Or syscall implementation or net / fd / etc implementation. > pkg/runtime should be easy. I'll do it tonight. It would be nice to avoid a system call if possible :-) ron
Re: [9fans] offered without comment or judgement
> Many banks still use 4 digit PINs on their ATM cards, without problem. > Possession is a very important factor. well, posscession and the fact that you only get three attempts to enter the PIN (in the UK at least), so brute force attacks are a non-starter, so limited kyspace is much less of a problem. -Steve
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
On Tue Jun 29 22:04:19 BST 2010, rminn...@gmail.com wrote: > Can someone remind me of the problem? Is it simply the need to be able > to set %gs? > > Could a write to /dev/arch of something like > gs 0xwhatever > which sets %gs for that process solve the problem? > > Or is it bigger than that? > > ron Ok, my turn with the bad memory. Isn't this exactly what cinap's patch did to allow recent debian releases to run under linuxemu? -Steve
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
>Or is it bigger than that? the go toolchain is replete with go-specific things, and produces incompatible .8 files (and perhaps for other architectures), because of the way certain changes were made. as russ suggested, it's probably easiest just to have a /bin/go and put go/8c, go/8l etc in that, as they exist. that would obviously work. he also suggested changing plan9's go/8l to rewrite references to offsets off GS as references to (say) offsets into the privstack data. you'd need to consider whether that would cover all cases correctly, although at the time i thought it would.
[9fans] megamouse?
http://warmouse.com/pr062810.html Looks complicated.
Re: [9fans] megamouse?
See also http://cyborggaming.com/ for complicated mice :) 2010/6/29 David Leimbach : > http://warmouse.com/pr062810.html > Looks complicated. > >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
the segment registers are just indices to the kernels descriptor tables. setting the segment registers can be done with assembly instructions from userspace. but what you need is being able to modify the descriptors in a save way from userspace! i needed this for linuxemu to implement set_thread_area syscalls under plan9 so i made the modifications to the kernel: /n/sources/contrib/cinap_lenrek/segdescpatch it adds the files ldt and gdt to devarch. heres a linuxemu process where glibc has setup a special descriptor and loaded %gs to point to it under plan9: cat /dev/gdt 000b data WPUBG3 1819c080 f 000c data -0 0 000d data -0 0 PC 0x00020439 pread+0x7 /sys/src/libc/9syscall/pread.s:5 SP 0xdeffcd70 ECODE 0xf010080c EFLAG 0x0286 CS 0x0023 DS0x001b SS 0x001b GS 0x005b FS0x ES 0x001b TRAP0x0040 system call AX 0x0032 BX 0x00032b4c CX 0x0001 DX 0x DI 0x080e7468 SI 0x BP 0xdeffcf2c format of is simple text: /* * format: * idx[4] type[8] flags[8] dpl[1] base[8] limit[5]\n */ idx is the descriptor index (the one you load into a segment registers by the selector) type is code or data dpl is the priority level (usualy just 3 for userspace) base and limit describe the location of the segment (limit is in pages if G flag is set) /* * flags: * P = present * A = accessed (for code/data) * E = expand down (for data) * W = writable (for data) * R = readable (for code) * C = conforming (for code) * G = limit granularity in pages (for code/data) * D = 32 bit operand size (for code) * B = 32 bit stack pointer (for data) * Y = busy (for tss and tss16) * U = available for use by system software */ gdt and ldt are both per process. the only difference between gdt and ldt is that gdt has a small fixed number of descriptors in the gdt that you can modify. the ldt refers to the local descriptor table wich can have up to 2^13 user descriptors. -- cinap --- Begin Message --- Can someone remind me of the problem? Is it simply the need to be able to set %gs? Could a write to /dev/arch of something like gs 0xwhatever which sets %gs for that process solve the problem? Or is it bigger than that? ron--- End Message ---
Re: [9fans] megamouse?
On 29 Jun 2010, at 11:17 pm, Devon H. O'Dell wrote: See also http://cyborggaming.com/ for complicated mice :) 2010/6/29 David Leimbach : http://warmouse.com/pr062810.html Looks complicated. Cyborg Gaming's R.A.T. I think I could do something with, but the warmouse? Get that think away from me! lol -- For purposes of orientation, if you find yourself in a steamy Devonian landscape and notice that a dragon is about to devour a beautiful girl nearby, you have undoubtedly stumbled into a lost world. Your problem is to save the girl and then live happily ever after with her. But if, on the other hand, you find yourself in Piccadily Circus, London, and notice that a beautiful girl is leading a dragon on a plastic lead down Regent Street, to no one's amazement but your own, then you are in a parallel world and your problems are entirely different.
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
what i said to people at usenix was approximately the following. i think that porting go to plan 9 - the time to get something working that runs all the go programs - is not more than a week of concerted effort. i also think that it just hasn't been high enough priority for anyone (myself included) to put that amount of effort in. the go runtime sets up the segment registers, with the operating system's help, so that gs points at per-kernel-thread storage. the linker generates references through gs for the pseudo-addressing mode 0(gs), 4(gs), etc. on plan 9 there is already per-kernel-thread storage: it is called the stack. the workaround would be for the linker to know the top of stack address and rewrite 0(gs) and 4(gs) to fixed memory addresses just below the top of the stack. it would be just as efficient as the 0(gs), 4(gs) stuff and not require any kernel changes. the build uses make, yes, and in some places there are even include files that include other include files (gasp!), but writing equivalent mkfiles should take not very much time. we're not doing anything magical, and the particular style in the makefiles should be familiar. there's obviously a lot of divergence between the plan 9 tool chain and the go tool chain. the object files have different format, and so on. to get off the ground i would suggest treating the go copies of the tools as separate programs and libraries from the originals. for example, you might install the go libmach as /386/lib/go/libmach.a and the compiler tool chain as /386/bin/go/8a, /386/bin/go/8c, /386/bin/go/8g, /386/bin/go/8l. the .8 files created by those tools would not be compatible with the standard ones, and the standard nm wouldn't understand the final 8.out, but the final 8.out would run. you'd have to disable the runtime copy of the symbol table (the "nacl" target in 8l already does). anyway, keep everything separate and get it working. once you have a working system then you could worry about reconciling the two worlds to whatever extent is appropriate. i think people get too hung up on trying to make the port back perfect. just make it work. then make it better. russ
Re: [9fans] megamouse?
On Tue, Jun 29, 2010 at 6:10 PM, David Leimbach wrote: > http://warmouse.com/pr062810.html > Looks complicated. > > Hey, there's a way to end the mouse/keyboard switching argument once and for all! With 18 buttons, you can just make the mouse a chording keyboard as well and never move your hand from the mouse. John -- "With MPI, familiarity breeds contempt. Contempt and nausea. Contempt, nausea, and fear. Contempt, nausea, fear, and .." -- Ron Minnich
Re: [9fans] megamouse?
On Jun 29, 2010, at 7:11 PM, John Floren wrote: Hey, there's a way to end the mouse/keyboard switching argument once and for all! With 18 buttons, you can just make the mouse a chording keyboard as well and never move your hand from the mouse. Amputees around the world jump for joy. Also as a side note, this was originally known as the OpenOffice.org Mouse. Hey! Let's make an acme/Wily Mouse; it'd totally sell!
