Although the web page is sparse on details (I might go so far as to say completely devoid) this isn't a bad idea. Getting folks together to develop a web of trust is the whole point of the PGP model. The more people who have signed your key, the more likely you and someone you don't know will have a common person that you both do know who has signed your keys. Without ever directly meeting them, you can put your trust in the common associate and send encrypted messages or verify digital signatures.
The problem is doing PGP signing the right way. I really suggest anyone attending one of these events take a look at web pages that describe "PGP Key Signing Parties" (just google, you'll find a bunch) to get the idea. In brief, to be absolutely sure that you trust a key belongs to someone, you need to verify the following:
The key ID (2BCA871D for example)
The key type (DSA, RSA, etc)
The key bits (768, 1024, 2048)
The key fingerprint (A028 82B4 14CC...)
Any one of these items can be forged while maintaining the others, so you need to verify them all.
Now, the hard part is how do you verify that this human who has brought these bits of data is the actual human associated with the key? You can check their driver's license and things like that. But of course this is where it's much better to only sign keys of people you know, rather than just total strangers.
Now I'd always heard that CVS' pserver wasn't the most stable or secure thing in the world, and that you should use CVS over SSH instead. However I also heard that the abilities of a CVS user were such that if they were determined enough, they'd be able to get shell-like access through the commands that are available. Thus you were only supposed to give CVS access to users who you also give shell access.
So my question is this: do the NetBSD folks have a page anywhere that describes their anonymous CVS setup? I assume they've done a secure job of locking it down to prevent the entire world from being able to get into their download server for obvious reasons.
The 4.x branch of MySQL do support subselects now. I don't know if every form of them is supported, but it's getting better.
For the 3.x which don't support any subselects whatsoever, they do have example that shows how you can often avoid a subselect by careful use of LEFT JOIN, but often the answer is "use a temporary table" or "post-process it in your application to generate the subsequent queries." I agree, lack of subselects are a show stopper for many complex apps. But for many uses, subselects aren't terribly necessary. Your simple e-commerce app will just be reading the items' price, pictures, description, and sticking customer orders into a different table - nothing terribly taxing.
From the review, this book talks about MySQL administration in one chapter, and covers the SQL stuff there as well. For the rest of the chapters they talk about how to interface with MySQL from Perl/PHP/etc. The beauty of the DBI interface in Perl is that you need to load the correct module to connect to a particular brand of database, but thereafter all the code is not database specific. $sth->fetchrow_arrayref() works whether you've got MySQL, PostgreSQL, Oracle, or anything else. So yeah, while you might not get the PostgreSQL administration info here, the rest is still relevant to how you interact with a database. Most Linux users don't do PostgreSQL because it's not an rpm-installable option.
If you're just using SSI to include header/sidebar/etc stuff, then what you should really do is save your CPU cycles and use WML. SSI requires each page get's rewritten each time, each 'exec' gets run each time. If you're just using it for the window dressing, you're better off with static pages.
That's where WML works - you can still keep all your window dressing in one place, you still include it automatically from your new docs, so no copy/paste problems or big hassles when you want to change the entire site - just change the included file. However WML then 'compiles' the.wml files into static.html files, so no SSI overhead. You serve "static" html that was generated via WML in a somewhat "dynamic" way. the best of both worlds.
According to the review, OSWB has a chapter on WML. I've never seen a book that covered it, and it's kind of hard to learn from scratch and the man pages, so I'd recommend you get the book. Yeah, I haven't read it, but Lee did a great job on Hacking Linux Exposed, I'm sure this is great too.
Slashdot Mirror
The problem is doing PGP signing the right way. I really suggest anyone attending one of these events take a look at web pages that describe "PGP Key Signing Parties" (just google, you'll find a bunch) to get the idea. In brief, to be absolutely sure that you trust a key belongs to someone, you need to verify the following:
- The key ID (2BCA871D for example)
- The key type (DSA, RSA, etc)
- The key bits (768, 1024, 2048)
- The key fingerprint (A028 82B4 14CC
...)
Any one of these items can be forged while maintaining the others, so you need to verify them all.Now, the hard part is how do you verify that this human who has brought these bits of data is the actual human associated with the key? You can check their driver's license and things like that. But of course this is where it's much better to only sign keys of people you know, rather than just total strangers.
Now I'd always heard that CVS' pserver wasn't the most stable or secure thing in the world, and that you should use CVS over SSH instead. However I also heard that the abilities of a CVS user were such that if they were determined enough, they'd be able to get shell-like access through the commands that are available. Thus you were only supposed to give CVS access to users who you also give shell access.
So my question is this: do the NetBSD folks have a page anywhere that describes their anonymous CVS setup? I assume they've done a secure job of locking it down to prevent the entire world from being able to get into their download server for obvious reasons.
For the 3.x which don't support any subselects whatsoever, they do have example that shows how you can often avoid a subselect by careful use of LEFT JOIN, but often the answer is "use a temporary table" or "post-process it in your application to generate the subsequent queries." I agree, lack of subselects are a show stopper for many complex apps. But for many uses, subselects aren't terribly necessary. Your simple e-commerce app will just be reading the items' price, pictures, description, and sticking customer orders into a different table - nothing terribly taxing.
From the review, this book talks about MySQL administration in one chapter, and covers the SQL stuff there as well. For the rest of the chapters they talk about how to interface with MySQL from Perl/PHP/etc. The beauty of the DBI interface in Perl is that you need to load the correct module to connect to a particular brand of database, but thereafter all the code is not database specific. $sth->fetchrow_arrayref() works whether you've got MySQL, PostgreSQL, Oracle, or anything else. So yeah, while you might not get the PostgreSQL administration info here, the rest is still relevant to how you interact with a database. Most Linux users don't do PostgreSQL because it's not an rpm-installable option.
That's where WML works - you can still keep all your window dressing in one place, you still include it automatically from your new docs, so no copy/paste problems or big hassles when you want to change the entire site - just change the included file. However WML then 'compiles' the .wml files into static .html files, so no SSI overhead. You serve "static" html that was generated via WML in a somewhat "dynamic" way. the best of both worlds.
According to the review, OSWB has a chapter on WML. I've never seen a book that covered it, and it's kind of hard to learn from scratch and the man pages, so I'd recommend you get the book. Yeah, I haven't read it, but Lee did a great job on Hacking Linux Exposed, I'm sure this is great too.