I downloaded the specification, but it's obnoxiously long/buzzwordish and my Linux PDF software sucks. I've got some pretty basic questions I'm hoping someone can answer:
Are passwords ever sent through service providers?
One would hope they are only sent to the identity provider, and encrypted. But this talk of using existing deployed clients makes me nervous, since I don't see how both things are possible together.
They mention HTTP redirects...I think you go to the Service Provider's page, they redirect you to the identity provider as the form action, and they redirect you back, authenticated. That doesn't seem like a good plan to me, no one will actually check that the form action goes elsewhere.
I'd be much more comfortable with something similar to Kerberos: you get a TGT (ticket-generating ticket) from the Key Distribution Center (excuse me, Identity Provider) and use that to provide a ticket to the Service Provider. That ticket can't be used elsewhere and will be invalidated after a certain length of time.
Does it work for protocols other than HTTP?
I'd like to use it to authenticate with HTTP, SSH, IMAP, SMTP, and Jabber - probably others I'm forgetting, too. A GSSAPI and/or SASL mechanism would help a lot here.
Who can set up providers?
I'd hope that anyone can set up Identity Providers and Service Providers at little or no cost and have them work with major players. I think this would require
a good Public Key Infrastructure. The existing X.500 PKI used for web stuff now costs ~ $100/yr/certificate to get a widely-trusted CA to sign your key. DNSSEC might end up being free (depends on what the TLD people do, I think) but isn't really deployed yet
addresses that make it obvious what Identity Provider they belong to. I.e., email-style with SRV records or something.
Can multiple Service Providers requiring the same credentials without knowing the identity is the same?
Here, I think the answer is yes. They said something about opaque tokens that gave me hope. I'd like clarification, though.
All you need to send an IM from one service to another is the username and domain, which would look like an e-mail address and might actually be an e-mail address.
Jabber addresses are like that.
When you send e-mail from one address to another, you send the message to your (ISP's) SMTP server, which looks up the domain name you're sending the message to, gets the SMTP server defined in the MX (mail exchange) record for the domain, and sends the message there. Under this proposal, a new record type would be added to DNS, an IMX record that specifies which server can handle IM connections.
This is how the Jabber transport works as well. Except that instead of creating a new DNS RR, they used SRV records. SRV records are a generalization of this concept. They are beginning to be used for LDAP, Kerberos, Jabber, etc. (Try "host -t srv _ldap._tcp.uiowa.edu", for example.)
That's really the only way to go. I will never be happy with instant messaging until it is decentralized like email. Providing a way of looking up the correct server with the address and the existing infrastructure (DNS) is the only way to go.
First, to answer the poster of this story. The TCPA forbids calling at the callee's expense. From this page:
In addition to prohibiting charges to protect residential privacy, the TCPA and our rules prohibit calls that impose costs on the called party (e.g., calls to paging and cellular numbers, facsimile advertisements).
After telling them I wished to be put on their no call list, they told me it would be three months before that would take effect. I told them this was unacceptable.
As well you should. I do not believe the TCPA allows them any time whatsoever. If they hang up and immediately call back, that's their one allowed error for the next twelve months. After that, you can charge them $500 per call.
I also learned that these no call lists are only valid for one year at which time they can opt me right back in
That's not what the TCPA says. This page at the Direct Marketing Assocation says that telemarketers must:
# Maintain a "do not call list" and honor any request to not be called again. When such a request is received, the requester may not be called again on behalf of the business for whom the solicitation is made. One error is allowed in a twelve month period. Subsequently, the soliciting companies are subject to penalties.
A person's name must be kept on the "do not call list" indefinitely.
I think the people who call just always try to weasel out of the terms and get you to agree. I try to be verify specific:
I find out what company is calling me ("We're calling on behalf of Sprint..." "Yes, but what company do you work for?") and say they may not call me again. I keep track of that.
I say "put me on your do-not-call list" rather than "take me off your list".
If they say "it will take 30 days", I say "it had better not".
Actually, browsing that Junkbusters site, they have a script for you to keep by the telephone. Looks handy.
You could get the same result by putting a malloc or fork call in a while(1) loop.
Not quite. X is kind of special, since it accesses hardware directly. (That's why it must run as root.) When it crashes, it could bring down the whole system or at least the console. A malloc/fork loop would run until stopped by the OOM killer on Linux, resource limits, or whatever.
Clearly, the font thing should be fixed in Mozilla and XFree86. But also...
IMHO, display drivers should be in the kernel, like all other drivers. But apparently (A) Linus doesn't want them there and (B) The XFree86 people don't want them there. IIRC the XFree86 people don't because XFree86 runs on many platforms and each driver would have to be in each kernel. Implausible unless you design a really standard API (and I don't know if you could really mask the differences between OSs. I.e., between a microkernel and a macrokernel). So I don't think this is likely.
Validating and non-validating processors alike must report violations of this specification's well-formedness constraints in the content of the document entity and any other parsed entities that they read.
I suspect it's there because of the reasons you mentioned.
...or read/compose your e-mail, or browse Avantgo-synced web pages, or wireless access to the 'net, or play games while you wait somewhere, or listen to MP3s, or watch DivX-encoded movies, or any number of modern conveniences.
Umm, I think someone's lost track of the request:
My memory is so poor I forget friends' birthdays and appointments I made a day ago. I sometimes have an idea I want to jot down but that I end up forgetting when I finally come upon pen & paper.
I agree with the grandparent of this post. The problem he described was not that he doesn't have a PDA. It's that he isn't carrying a note-taking device - either the PDA (it doesn't help at home!) or the pad of paper. A notepad is faster to write on (no matter what the Palm people say), more reliable, and more indestructible than a PDA can dream of.
On the other hand, the fact that he asked for a PDA suggests to me that the memory problems are really just an excuse to play with a cool toy. *shrug* And if that's the case, original poster - sucks to be you. When you don't say what you want, it's hard to recommend something.
Ever heard of left-handed people? We can't use the WASD configuration (not easily, anyhow) because we have our left hand on the mouse.
I'm left-handed and always liked this arrangement. I have no problem putting my right hand on those keys. Possibly this is related to my keyboard - an old true blue IBM PS/2 keyboard; the kind with the big clicking keys you can pop the keycaps off easily. All the keycaps but a few odd-sized ones (modifiers, enter, baskspace, tab, numeric +/insert, space) are the same except for the coloring/lettering and the little bars on the 'F' and 'J' to orient your hands. No tilting or anything. So the left and right parts of the keyboard are equally comfortable for either hand.
And in any case, I don't think it's a great stretch of imagination to extend the "WASD" concept to a different part of the keyboard. This is why games have configurable keys.
That's the most asinine thing I've ever heard. I don't personally know anyone who doesn't use the numpad for entering numbers.
I don't. I try not to move my hands from the home row. With most simple editors I have to use the arrows (to highlight/delete stuff in this text, ironically enough) but I avoid the number keys. I suppose I could be more efficient entering lots of numbers with the keypad, but I simply never do that. It would be dumb for me to move my hands off the home row for the short numbers I enter. And I'm faster with it than a lot of people are with the numeric keypad anyway.
And you neglected to include this part of the original post:
If you really need a numeric keyboard, you should be able to buy it separately.
Here's an idea: get a clue, and the consider revising your list.
Here's an idea: be less hostile, so people won't call you a troll or flamebait.
Right, the _exploiter_ has to have something listening for gopher connections, but the _exploitee_ (i.e., the user being rooted) only has to click on a link or visit a site that happens to be malicious.
No, you misunderstood. The connection must actually be completed for the exploit to work. That is the key distinction here, between a buffer overflow in the URL handling and a buffer overflow in interpreting replies from the gopher server. That is why the proxy workaround is successful.
Had you read the article, you do not need to have a Gopher server running. It is a URL buffer overflow in the Gopher protocol.
No, the article doesn't say that. And from the bugtraq posting:
The attack can be launched via a web page or an HTML mail message which
redirect the user to a malicious gopher server when the victim views them.
The server can be very minimal, ie. a program that can listen on a TCP
port and write a block of data; a fully operational gopher server isn't
necessary in order to carry out the attack.
So it seems it is a buffer overflow in handling responses from gopher servers, not in the gopher URL. And they propose the workaround mentioned here of setting a proxy server for gopher that can never be accessed (localhost:someunusedtcpport).
That won't help. The port can be specified in the URL. Haven't you seen links like <a href="gopher://nowhere.com:79/bob">finger bob@nowhere.com</a> before? (An old trick - using the gopher support for finger instead.)
You're counting on RPM checksums to verify your data when you should do your own independant fingerprinting of binaries (which is about 10 minutes to script). An changes in filesystem outside of variable data should be noted automatically.
And how is this database maintained? A simple script that makes checksums nightly and compares them to the current files? (As stock FreeBSD does for setuid binaries.) Then if someone is determined, (s)he could just change the checksum as well. It sounds like you are depending on security through obscurity - no one knows your checksum system is there, so no one would do that.
In contrast, the RPM way includes a GPG signature with every package. The checksums are signed. If you make your own RPMs, you can do so on your testing system, with a private key not stored on the machine you are checking. Then you know the database is trustworthy.
Why would your way be superior? I've shown one way it might not even be as good. Even if you've avoided that pitfall (sending the checksums somewhere else, perhaps), there's the problem of knowing if the changes are authorized or not - with a RPM, updating the package and the checksum always happens at once. With something like TripWire, you have to remember and/or tell other admins you changed this package. There are surely other pitfalls I can't think of now.
Any lack pf super high-level automation is not a disadvantage, it's traditional systems administration.
It is indeed traditional systems administration. However, I find it to be a disadvantage compared to RPM. Rejecting things because they are not traditional is dumb. Please explain to me why your way is better, if you can.
OpenBSD a long time ago, FreeBSD fairly recently. (Upgraded until about 4.4.)
The initial install of FreeBSD is ALL packages. [...] Lastly, to address your issue with the "base system" not being packaged, that too is dead wrong. There are regular binary package snapshots created of the STABLE tree.
This does not match my experience. A "pkg_info -a" would not show the base system. On RedHat, it certainly does - divided up into many different RPMs as appropriate.
I particularly noticed that it's divided up into many different RPMs because this is important. For example, I really don't like sendmail. It's nice to completely remove it from the system with a simple "rpm -e sendmail". (As to why I don't like it, look through my older postings here.)
Let me give another reason package management is useful. If you use the RedHat Network (or similar things), you will get an email notification whenever a security advisory applies to your system. No false alarms and you always get the notification, if the relevant stuff is an official RedHat package. (So you just need to watch anything you don't get from RedHat, and there's surprisingly little in that category.) Another of the many reasons why it is useful to have an accurate inventory of your system.
Don't have a package? Make one! Every port can be built into a package to distribute to other machines in a binary form.
True, I've never had a problem getting a package from a port. And I think it's not hard to make a port from plain source, either. I never said otherwise. I've done analogous things with.src.rpms on RedHat.
This is either FUD or ignorance. If you're dead serious about knowing whether or not files have been tampered with you wouldn't even consider RPM as your first line of defense. You'd be scripting your own MD5 summaries, or running something like TripWire.
You are very dismissive, yet give no reasons for believing these methods are superior. RPMs are signed with GPG signatures and come with MD5 signatures for each file (as well as much other metainformation). It is updated whenever you update the packages. TripWire, IIRC, just makes comparisons against arbitrary points in time, with no knowledge if the changes are authorized.
Also, your use of the phrase "first line of defense" is completely inappropriate. Prevention is the first line of defense. Checking if your system has been compromised is not. If it is, you are doing something horribly, horribly wrong.
I honestly don't see how the installation program is difficult to use. I have heard many people complain about it, but it's not hard to use at all. Of course I haven't used any recent Linux installers (last Linux I used was Slackware 7) with all the dumbed-down GUI luvin', but I still fail to see how a straightforward ANSI menu system is confusing and difficult?!
Well, don't take our word for it. Read here why Jordan Hubbard thinks it sucks - and he wrote it. (Section 2.2 describes sysinstall.) A select quote:
dialog(3) is also extremely limited in the user-friendliness
department and lacks features like the ability to put more than 2
buttons into a dialog or a Yes/No dialog which had a selectable
default (e.g. No). The inability to put a "Back" button into various
dialogs which could really use one or the necessity for asking only
"positive" questions are outgrowths of those limitations and good
examples of how an insufficiently powerful UI library can drive the
utility-writer in undesirable but unavoidable directions.
It also describes various reasons the ports system sucks, though "hard to use" isn't on my list. My major complaint with it is that the "base system" isn't packaged. With a RedHat system it is, and you can really take advantage of this. For example, when doing a security audit, boot from external media, check the GPG signatures in the package database, do a "rpm -Va", and make sure nothing extra is in suspicous places. ("rpm -qal" to get a list of what should be there, a "find" command to get what actually is.) You then know no binaries have been tampered with. With a BSD system, you pretty need to reinstall.
There are legitimate reasons to dislike these systems. It's all about weighing the choices - some new FreeBSD 5.0 features (KSEs in particular) sound interesting enough that I might switch a system or two back to BSD when it's released.
I'm not saying you necessarily showed this attitude in the actual interviews, but it's something to watch.
Ergh. You didn't get actual interviews. Think-o there. I meant to say, in your cover letters. (I think you can convey that even in a cover letter and you certainly don't want to. "I want to work for your company." "How do you know that, since you don't yet know anything about our company?")
Whether I work as programmer, sys admin or something else isn't an issue, since I need any job at this point
My boss recently hired someone here, and he was saying that while the candidates seemed eager, very few asked good questions or showed a lot of specific interest in this position. I think, like you, they wanted any job they could get. This attitude didn't really impress him.
The lesson, I think, is that you absolutely have to sound like you want this job, not any job. They're not going to hire you if they think you will immediately leave when you find something you like better, etc.
I'm not saying you necessarily showed this attitude in the actual interviews, but it's something to watch.
Take a look at these files. This project is basically an example of what not to do. It's faggotted up like a twelve-year-old schoolgir's notebook, to borrow a phrase from The Onion. In particular,
The huge block comments have these banners that are at column 1, in complete defiance of the indentation. Consequently, the indentation is not at all consistent across the code. It makes it difficult to visually see what level you are at. It makes using a folding text editor impossible.
there are lots of comments along the lines of "// slamb was here, 4-26-02". These are things much more appropriate for a version control system (cvs annotate). They clutter up the code unnecessarily.
the comments that are there explain nothing. For example,
// This is the main method that Java invokes at start-up
That should be obvious from the "public static void main (String argv[])".
They are not in the proper form for Javadoc, Doxygen, or any other documentation generator. If you go to the trouble of putting comments at the beginning of methods in structured way, you should do so in a way that can be used to generate easily browsable documentation. See Writing Documentation Comments at Sun.
The grammar is inconsistent and awkward. That same document gives hints on making useful documentation with grammar that does not distract.
The code is not self-documenting. If you adhere to a consistent coding standard, like Sun's Code Conventions, you will know what a lot of stuff is without resorting to comments at all.
Programmers fired for not updating documentation? What planet do you program on?
Wishful thinking and low blood sugar may have been involved. In any case, I was trying to say that paying attention to the documentation would avoid bugs, and the bugs would get him fired eventually. Even so, you're probably right.
Comments should only be used when absolutely necessary, which is maybe 10% of what doxygen requires.
What gave you the idea that doxygen requires you to add a fixed number of comments? If you set EXTRACT_ALL in the doxygen configuration file, then it will generate output for all classes/functions/#defines/whatevers, whether they are documented or not.
In fact, I find doxygen is useful even for libraries which do not use its documentation comments at all. It generates other helpful things, like inheritance/collaboration/dependency diagrams(*) and quick summaries of the members of a given class.
So simply turn on that option and make the 10% of comments you feel are necessary. Run doxygen. I think you will be pleasantly surprised at the results.
(*) - If you don't see all these diagrams in your doxygen, you probably haven't installed AT&T's graphviz or haven't told doxygen that it is present. And I think each can be toggled in the config file individually. Take the time to download this software and turn on the options.
So what happens when the code changes and breaks the assumptions so fastidiously outlined in the documentation?
You know what pre- and post-conditions are no longer true, so you can fix the bugs you've introduced. If you actually read the documentation, you can fix the bug before it's a problem. If you don't, your successor will have an easier time fixing the bug after you're fired.
Sendmail in OpenBSD hasn't run as root since 2.9 [openbsd.org].
That's a very good change that I wasn't aware of. However, I'll keep running Postfix: user-level access is a stepping stone to full root, especially outside of a chroot() jail, since setuid executables are available to be exploited.
Theo and team seem confident in Sendmail's security. They've spent upwards of 30 hours going through the source and reporting bugs.
When did this happen? It would be interesting to know if any of the security bugs I linked to were reported after this audit was completed. That would be proof that their confidence was misplaced. (However, even if not, I still would not trust sendmail - the real question is of course what bugs remain, not what bugs have been discovered.)
Keep in mind that you can easily disable sendmail and go to postfix or another mail transfer agent through the ports tree if you don't trust Theo's judgement.
Yes, this is exactly what I used to do when I ran OpenBSD. It would be preferable if all outside packages were in ports rather than the main tree, to make completely removing sendmail more convenient.
My pen-tester co-workers have the same knee-jerk reaction to sendmail that you have.
It's not a knee-jerk reaction. Did you look at the links I posted? Postfix is secure by design. Sendmail is not.
Funny though, not one of them has been able to penetrate any of my OpenBSD boxes, through sendmail or any other avenue.
I have never exploited a new sendmail vulnerability, either. However, I am not convinced that no vulnerabilities remain to be exploited. I prefer to use something like Postfix - proper compartimentalization, much less code to be audited, so I have more faith in its correctness.
(Still not complete faith. My ideal system would have all network services implemented in a high-level language like Java. It is good to completely eliminate entire classes of vulnerabilities (buffer overflows, format strings) that occur over and over and over in software everyone uses. But comparable software does not yet exist in these languages, or I am unaware of it.)
That seems to be just 2001 ones. I'm sure there have been problems between 1988 and 2001; I just don't care enough to find them right now.
Okay, I'm bored today. here are some more. These two lists together may still not be exhaustive, but they are definitely long enough to prove my point that sendmail's security track record is very bad.
Since it sounds like this was a P4 specific issue, and a P4 specific fix, shouldn't it have been #ifdef'ed for the architecture?
Besides the reasons VAXman gave, it's common for distributors to create a lowest common denominator kernel for installation. So if a change is necessary to get P4 to work (rather than just an optimization), it should be included in the i386 kernel. So it affects all x86-based chips.
Why people think that sendmail is automatically insecure is beyond me.
Sendmail is fundamentally insecure. It is a single, monolithic process running as root - not necessary for most of its operations. A single buffer overflow would completely compromise the machine running sendmail. It was originally written with little regard to security and has a long lifespan, accumulating cruft. It should be no surprise that it has had several vulnerabilities over the years. (That seems to be just 2001 ones. I'm sure there have been problems between 1988 and 2001; I just don't care enough to find them right now.)
In contrast, Postfix is broken apart into several different processes. Each executes at the minimum privelege necessary to do its job. A process running as an unprivileged user inside a chroot() jail containing no setuid binaries is a minimum risk to the system. The entire system was constructed with a focus on security - both eliminating vulnerabilities like buffer overflows and minimizing their impact should they occur. It has, by comparison, an unblemished security record.
For more information on why Postfix's security is completely superior to sendmail's, please see this page.
Slashdot Mirror
I downloaded the specification, but it's obnoxiously long/buzzwordish and my Linux PDF software sucks. I've got some pretty basic questions I'm hoping someone can answer:
One would hope they are only sent to the identity provider, and encrypted. But this talk of using existing deployed clients makes me nervous, since I don't see how both things are possible together.
They mention HTTP redirects...I think you go to the Service Provider's page, they redirect you to the identity provider as the form action, and they redirect you back, authenticated. That doesn't seem like a good plan to me, no one will actually check that the form action goes elsewhere.
I'd be much more comfortable with something similar to Kerberos: you get a TGT (ticket-generating ticket) from the Key Distribution Center (excuse me, Identity Provider) and use that to provide a ticket to the Service Provider. That ticket can't be used elsewhere and will be invalidated after a certain length of time.
I'd like to use it to authenticate with HTTP, SSH, IMAP, SMTP, and Jabber - probably others I'm forgetting, too. A GSSAPI and/or SASL mechanism would help a lot here.
I'd hope that anyone can set up Identity Providers and Service Providers at little or no cost and have them work with major players. I think this would require
Here, I think the answer is yes. They said something about opaque tokens that gave me hope. I'd like clarification, though.
Jabber addresses are like that.
When you send e-mail from one address to another, you send the message to your (ISP's) SMTP server, which looks up the domain name you're sending the message to, gets the SMTP server defined in the MX (mail exchange) record for the domain, and sends the message there. Under this proposal, a new record type would be added to DNS, an IMX record that specifies which server can handle IM connections.
This is how the Jabber transport works as well. Except that instead of creating a new DNS RR, they used SRV records. SRV records are a generalization of this concept. They are beginning to be used for LDAP, Kerberos, Jabber, etc. (Try "host -t srv _ldap._tcp.uiowa.edu", for example.)
That's really the only way to go. I will never be happy with instant messaging until it is decentralized like email. Providing a way of looking up the correct server with the address and the existing infrastructure (DNS) is the only way to go.
First, to answer the poster of this story. The TCPA forbids calling at the callee's expense. From this page:
After telling them I wished to be put on their no call list, they told me it would be three months before that would take effect. I told them this was unacceptable.As well you should. I do not believe the TCPA allows them any time whatsoever. If they hang up and immediately call back, that's their one allowed error for the next twelve months. After that, you can charge them $500 per call.
I also learned that these no call lists are only valid for one year at which time they can opt me right back in
That's not what the TCPA says. This page at the Direct Marketing Assocation says that telemarketers must:
I think the people who call just always try to weasel out of the terms and get you to agree. I try to be verify specific:
Actually, browsing that Junkbusters site, they have a script for you to keep by the telephone. Looks handy.
That means the only computers in Iowa are in this room! That's amazing!
Not quite. X is kind of special, since it accesses hardware directly. (That's why it must run as root.) When it crashes, it could bring down the whole system or at least the console. A malloc/fork loop would run until stopped by the OOM killer on Linux, resource limits, or whatever.
Clearly, the font thing should be fixed in Mozilla and XFree86. But also...
IMHO, display drivers should be in the kernel, like all other drivers. But apparently (A) Linus doesn't want them there and (B) The XFree86 people don't want them there. IIRC the XFree86 people don't because XFree86 runs on many platforms and each driver would have to be in each kernel. Implausible unless you design a really standard API (and I don't know if you could really mask the differences between OSs. I.e., between a microkernel and a macrokernel). So I don't think this is likely.
there should be a standard on what to do with badly formed HTML too.
There is such a standard for XML:
I suspect it's there because of the reasons you mentioned.
Umm, I think someone's lost track of the request:
I agree with the grandparent of this post. The problem he described was not that he doesn't have a PDA. It's that he isn't carrying a note-taking device - either the PDA (it doesn't help at home!) or the pad of paper. A notepad is faster to write on (no matter what the Palm people say), more reliable, and more indestructible than a PDA can dream of.
On the other hand, the fact that he asked for a PDA suggests to me that the memory problems are really just an excuse to play with a cool toy. *shrug* And if that's the case, original poster - sucks to be you. When you don't say what you want, it's hard to recommend something.
I'm left-handed and always liked this arrangement. I have no problem putting my right hand on those keys. Possibly this is related to my keyboard - an old true blue IBM PS/2 keyboard; the kind with the big clicking keys you can pop the keycaps off easily. All the keycaps but a few odd-sized ones (modifiers, enter, baskspace, tab, numeric +/insert, space) are the same except for the coloring/lettering and the little bars on the 'F' and 'J' to orient your hands. No tilting or anything. So the left and right parts of the keyboard are equally comfortable for either hand.
And in any case, I don't think it's a great stretch of imagination to extend the "WASD" concept to a different part of the keyboard. This is why games have configurable keys.
That's the most asinine thing I've ever heard. I don't personally know anyone who doesn't use the numpad for entering numbers.
I don't. I try not to move my hands from the home row. With most simple editors I have to use the arrows (to highlight/delete stuff in this text, ironically enough) but I avoid the number keys. I suppose I could be more efficient entering lots of numbers with the keypad, but I simply never do that. It would be dumb for me to move my hands off the home row for the short numbers I enter. And I'm faster with it than a lot of people are with the numeric keypad anyway.
And you neglected to include this part of the original post:
Here's an idea: get a clue, and the consider revising your list.
Here's an idea: be less hostile, so people won't call you a troll or flamebait.
No, you misunderstood. The connection must actually be completed for the exploit to work. That is the key distinction here, between a buffer overflow in the URL handling and a buffer overflow in interpreting replies from the gopher server. That is why the proxy workaround is successful.
No, the article doesn't say that. And from the bugtraq posting:
So it seems it is a buffer overflow in handling responses from gopher servers, not in the gopher URL. And they propose the workaround mentioned here of setting a proxy server for gopher that can never be accessed (localhost:someunusedtcpport).
That won't help. The port can be specified in the URL. Haven't you seen links like <a href="gopher://nowhere.com:79/bob">finger bob@nowhere.com</a> before? (An old trick - using the gopher support for finger instead.)
I'm sure. A while back, a local telemarketing company came down with lice. The whole company, or pretty close.
And how is this database maintained? A simple script that makes checksums nightly and compares them to the current files? (As stock FreeBSD does for setuid binaries.) Then if someone is determined, (s)he could just change the checksum as well. It sounds like you are depending on security through obscurity - no one knows your checksum system is there, so no one would do that.
In contrast, the RPM way includes a GPG signature with every package. The checksums are signed. If you make your own RPMs, you can do so on your testing system, with a private key not stored on the machine you are checking. Then you know the database is trustworthy.
Why would your way be superior? I've shown one way it might not even be as good. Even if you've avoided that pitfall (sending the checksums somewhere else, perhaps), there's the problem of knowing if the changes are authorized or not - with a RPM, updating the package and the checksum always happens at once. With something like TripWire, you have to remember and/or tell other admins you changed this package. There are surely other pitfalls I can't think of now.
Any lack pf super high-level automation is not a disadvantage, it's traditional systems administration.
It is indeed traditional systems administration. However, I find it to be a disadvantage compared to RPM. Rejecting things because they are not traditional is dumb. Please explain to me why your way is better, if you can.
OpenBSD a long time ago, FreeBSD fairly recently. (Upgraded until about 4.4.)
The initial install of FreeBSD is ALL packages. [...] Lastly, to address your issue with the "base system" not being packaged, that too is dead wrong. There are regular binary package snapshots created of the STABLE tree.
This does not match my experience. A "pkg_info -a" would not show the base system. On RedHat, it certainly does - divided up into many different RPMs as appropriate.
I particularly noticed that it's divided up into many different RPMs because this is important. For example, I really don't like sendmail. It's nice to completely remove it from the system with a simple "rpm -e sendmail". (As to why I don't like it, look through my older postings here.)
Let me give another reason package management is useful. If you use the RedHat Network (or similar things), you will get an email notification whenever a security advisory applies to your system. No false alarms and you always get the notification, if the relevant stuff is an official RedHat package. (So you just need to watch anything you don't get from RedHat, and there's surprisingly little in that category.) Another of the many reasons why it is useful to have an accurate inventory of your system.
Don't have a package? Make one! Every port can be built into a package to distribute to other machines in a binary form.
True, I've never had a problem getting a package from a port. And I think it's not hard to make a port from plain source, either. I never said otherwise. I've done analogous things with .src.rpms on RedHat.
This is either FUD or ignorance. If you're dead serious about knowing whether or not files have been tampered with you wouldn't even consider RPM as your first line of defense. You'd be scripting your own MD5 summaries, or running something like TripWire.
You are very dismissive, yet give no reasons for believing these methods are superior. RPMs are signed with GPG signatures and come with MD5 signatures for each file (as well as much other metainformation). It is updated whenever you update the packages. TripWire, IIRC, just makes comparisons against arbitrary points in time, with no knowledge if the changes are authorized.
Also, your use of the phrase "first line of defense" is completely inappropriate. Prevention is the first line of defense. Checking if your system has been compromised is not. If it is, you are doing something horribly, horribly wrong.
I honestly don't see how the installation program is difficult to use. I have heard many people complain about it, but it's not hard to use at all. Of course I haven't used any recent Linux installers (last Linux I used was Slackware 7) with all the dumbed-down GUI luvin', but I still fail to see how a straightforward ANSI menu system is confusing and difficult?!
Well, don't take our word for it. Read here why Jordan Hubbard thinks it sucks - and he wrote it. (Section 2.2 describes sysinstall.) A select quote:
It also describes various reasons the ports system sucks, though "hard to use" isn't on my list. My major complaint with it is that the "base system" isn't packaged. With a RedHat system it is, and you can really take advantage of this. For example, when doing a security audit, boot from external media, check the GPG signatures in the package database, do a "rpm -Va", and make sure nothing extra is in suspicous places. ("rpm -qal" to get a list of what should be there, a "find" command to get what actually is.) You then know no binaries have been tampered with. With a BSD system, you pretty need to reinstall.
There are legitimate reasons to dislike these systems. It's all about weighing the choices - some new FreeBSD 5.0 features (KSEs in particular) sound interesting enough that I might switch a system or two back to BSD when it's released.
Ergh. You didn't get actual interviews. Think-o there. I meant to say, in your cover letters. (I think you can convey that even in a cover letter and you certainly don't want to. "I want to work for your company." "How do you know that, since you don't yet know anything about our company?")
My boss recently hired someone here, and he was saying that while the candidates seemed eager, very few asked good questions or showed a lot of specific interest in this position. I think, like you, they wanted any job they could get. This attitude didn't really impress him.
The lesson, I think, is that you absolutely have to sound like you want this job, not any job. They're not going to hire you if they think you will immediately leave when you find something you like better, etc.
I'm not saying you necessarily showed this attitude in the actual interviews, but it's something to watch.
Take a look at these files. This project is basically an example of what not to do. It's faggotted up like a twelve-year-old schoolgir's notebook, to borrow a phrase from The Onion. In particular,
That should be obvious from the "public static void main (String argv[])".
Wishful thinking and low blood sugar may have been involved. In any case, I was trying to say that paying attention to the documentation would avoid bugs, and the bugs would get him fired eventually. Even so, you're probably right.
What gave you the idea that doxygen requires you to add a fixed number of comments? If you set EXTRACT_ALL in the doxygen configuration file, then it will generate output for all classes/functions/#defines/whatevers, whether they are documented or not.
In fact, I find doxygen is useful even for libraries which do not use its documentation comments at all. It generates other helpful things, like inheritance/collaboration/dependency diagrams(*) and quick summaries of the members of a given class.
So simply turn on that option and make the 10% of comments you feel are necessary. Run doxygen. I think you will be pleasantly surprised at the results.
(*) - If you don't see all these diagrams in your doxygen, you probably haven't installed AT&T's graphviz or haven't told doxygen that it is present. And I think each can be toggled in the config file individually. Take the time to download this software and turn on the options.
You know what pre- and post-conditions are no longer true, so you can fix the bugs you've introduced. If you actually read the documentation, you can fix the bug before it's a problem. If you don't, your successor will have an easier time fixing the bug after you're fired.
That's a very good change that I wasn't aware of. However, I'll keep running Postfix: user-level access is a stepping stone to full root, especially outside of a chroot() jail, since setuid executables are available to be exploited.
Theo and team seem confident in Sendmail's security. They've spent upwards of 30 hours going through the source and reporting bugs.
When did this happen? It would be interesting to know if any of the security bugs I linked to were reported after this audit was completed. That would be proof that their confidence was misplaced. (However, even if not, I still would not trust sendmail - the real question is of course what bugs remain, not what bugs have been discovered.)
Keep in mind that you can easily disable sendmail and go to postfix or another mail transfer agent through the ports tree if you don't trust Theo's judgement.
Yes, this is exactly what I used to do when I ran OpenBSD. It would be preferable if all outside packages were in ports rather than the main tree, to make completely removing sendmail more convenient.
My pen-tester co-workers have the same knee-jerk reaction to sendmail that you have.
It's not a knee-jerk reaction. Did you look at the links I posted? Postfix is secure by design. Sendmail is not.
Funny though, not one of them has been able to penetrate any of my OpenBSD boxes, through sendmail or any other avenue.
I have never exploited a new sendmail vulnerability, either. However, I am not convinced that no vulnerabilities remain to be exploited. I prefer to use something like Postfix - proper compartimentalization, much less code to be audited, so I have more faith in its correctness.
(Still not complete faith. My ideal system would have all network services implemented in a high-level language like Java. It is good to completely eliminate entire classes of vulnerabilities (buffer overflows, format strings) that occur over and over and over in software everyone uses. But comparable software does not yet exist in these languages, or I am unaware of it.)
Okay, I'm bored today. here are some more. These two lists together may still not be exhaustive, but they are definitely long enough to prove my point that sendmail's security track record is very bad.
Besides the reasons VAXman gave, it's common for distributors to create a lowest common denominator kernel for installation. So if a change is necessary to get P4 to work (rather than just an optimization), it should be included in the i386 kernel. So it affects all x86-based chips.
Sendmail is fundamentally insecure. It is a single, monolithic process running as root - not necessary for most of its operations. A single buffer overflow would completely compromise the machine running sendmail. It was originally written with little regard to security and has a long lifespan, accumulating cruft. It should be no surprise that it has had several vulnerabilities over the years. (That seems to be just 2001 ones. I'm sure there have been problems between 1988 and 2001; I just don't care enough to find them right now.)
In contrast, Postfix is broken apart into several different processes. Each executes at the minimum privelege necessary to do its job. A process running as an unprivileged user inside a chroot() jail containing no setuid binaries is a minimum risk to the system. The entire system was constructed with a focus on security - both eliminating vulnerabilities like buffer overflows and minimizing their impact should they occur. It has, by comparison, an unblemished security record.
For more information on why Postfix's security is completely superior to sendmail's, please see this page.