1) You can use a different logger with systemd 2)To watch log messages with journal, journalctl -f
There are still some things I don't like about the journal (I haven't seen how to specify different retention rules for logs of different applications), but then I've only spent a few minutes actively using it.
Maybe the thing that irritates me about journal is I don't know what previously unsolved problem it is trying to solve, while making some log processing difficult.
But, if you are booting from CDs, and the CD has the rest of the media, why do you need the utility for verifying signatures on the boot media (1.44MB image)? Bootstrap the installation image from the iso9660 part of the CD (or network in the case if a network install)? and have that contain the signature verification utility.
Hint: RPM-baswd distro have been doing this since rpm 3.x, or about 1999.
Really, who uses floppies for installation these days? Sure, maybe floppy emulation on a DRAC or iLO or ILOM, but they all -support CDROM or DVD emulation -PXE boot (with relatively large images possible via TFTP)
If none of these are options, just write the whole (hybrid) ISO image to a 4GB USB flash disk and be done with it.
I personally haven't used an actual CD-RW or DVD to install a syatem in about 5 years. Either network install booted via PXE for servers, or USB flash disk for laptops.
Unless your boot is "Please enter password to boot up computer" before it can boot the OS.
Of course it is. Any other FDE is the sprinkling of magic encryption dust kind of FDE. Both initscripts (on RH-style systems) and systemd support this, and have for years.
c) full-disk encryption can be tricky to do right on laptops, which are the main user of WiFi.
Why?
I have been using full (or, full enough,/boot isn't encrypted) disk encryption on my laptops for years. Since my only non-laptop is a workstation in a secure facility, I only did full disk encryption on that a few months after first doing it on my laptop (which is a much bigger security risk than my workstation).
I have used KDE for a long time. My laptop has an embedded 3G card that works better / more easily with NetworkManager/ModemManager than with more traditional (e.g. pppd, wvdial etc.) setups. Thus, I tried KNetworkManager.
However, I use WiFi networks with both WPA2 Personal, and WPA2 Enterprise, security. I don't mind my WiFi keys for the WPA2 Personal networks being stored somewhere, but I don't want my passwords for WPA2 Enterprise networks stored *anywhere*. Before trying NetworkManager/KNetworkManager, I would have all the WiFi configuration in/etc/wpa_supplicant.conf except the username and password, and run wpa_gui. The first time a specific instance of wpa_supplicant connected to said WiFi network, wpa_gui would pop up a dialog prompting for username and password, and I wouldn't need to enter the same credentials for the lifetime of that wpa_supplicant process (typically longer than the lifetime of the password).
However, with KNetworkManager, my options are: -Store -Always Ask
In the 'Store' case, due to my KDE Wallet settings (including 'close when screensaver starts'), now every time I resume my laptop, I will be prompted to enter my KDE wallet password (longer/more complex than the WPA Enterprise password).
In the 'Always Ask' case, I am required to enter my password *every* *time* I associate to the the SSID.
So, maybe it is better than nm-applet (I haven't used nm-applet *that* much) or the Gnome 3 integration (which I only see when trying to help a colleague), but it most definitely isn't better than the old/etc/sysconfig/network-scripts in conjunction with wpa_supplicant approach that I have been using for the past 7 years. On Mandriva (and Mageia), the net_applet tool can do all that configuration anyway, so there really doesn't seem to be any benefit. Of course, systemd will most likely require NetworkManager only at some point. I hope someone fixes NetworkManager to be more sane before then.
At present, I don't care about having a WiFi network connected before a user is logged in. Surely on a typical laptop, that occurs once a month or so? We have network authentication with cached crendentials, and I can kinit after logging in anyway. If this is really a requirement, using TPM (with all of its failings) would probably be a better approach.
And all platforms that support EAP support PEAP with MSCHAPv2.
Any network that does PEAP with MSCHAPv2 using credentials thay are usee dor any other service is vulnerable, unless the clients will require certificates signed by a trusted CS cert.
Android authenticating via FreeRADIUS to Samba password hashes to allow access to an AP running OpenWRY would be vulnerable by default.
EAP is performed when the EAP client is trying to establish layer 2 connectivity, before IP address aasignment can happed. Since there is no IP, there is no way to do a DNS lookup, and nothing to validate the subject cn against.
If certificate validation against CA certificates is disabled by default ( which is the case on Android as well), certificate validation collapses to whether the cert has expired.
I am only aware of 2 mobile platforms that do this better, iOS which prompts on a new EAP certificate, and Symbian, which didn't allow connecting to EAP networks with certs not signed by a trusted cert.
The recent 'it just works' race to the least secure is not going to end well.
How would those who are opposed to DRM ensure that artists will get just compensation for their works if there are no mechanisms to prevent someone from simply digitally copying a work (be it music, movie or book) and giving it away to anyone who wants it?
If it were me, I would:
Give the people who pay for a legitimate license for the work something that is of value to them, but costs you nothing.
Don't artificially increase the cost of distributing works.
Allow people to copy the work, and reward them for licensing it
Ensure that nothing besides access to the file storing the content is required for enjoying the work.
Build in some features to validate the authenticity of the work.
Allow the user to backup just the signatures
For example, in a container format that supports separate streams and meta-data, store an x.509 certificate or PGP signature by a licensing representative of the artist of the content's digest/hash and the customer's details (e.g. name).
Have playback/display software show the content that has such a signature differently, e.g. a badge with the customer's details from the signature.
Allow a user who has copied the content from someone else to buy just a license for the content, and all you need to do is:
Vlidate the hash of the content to ensure they have the copy you want them to have
Issue a new cert/signature
Of course, some changes to media consumption software would be required to support this model.
I would definitely be motivated to license more of the works I have copied if it was easy, didn't require downloading new versions, and had something more attractive to me. There is currently almost nothing to distinguish works I have paid for from ones I haven't (except that I store them separately). For most users, the only distinguishing factor is that the one they haven't paid for is easier to use.
I'm wondering what's wrong with "scp -rp ~/.ssh user@host:~/" (assuming pword auth can be enabled momentarily).
1)PasswordAuthentication no
(One of the reasons to use keys is to avoid password cracking, and/or enforce two-factor/multi-factor authentication/authorizaion in conjunction with sudo or a VPN or similar)
2)AuthorizedKeysFile/etc/ssh/keys/%u.pub
(Many security frameworks don't allow non-administrative users to have full control over keys, as this can lead to abuse, such as a member of the dba group, who can run certain commands as the oracle user with auditing, giving him/herself unrestricted/unaudited access to the oracle user account. Another example is if there are restrictions in the aurhorized keys entry, such as forced command, or sources that can use the key via 'from', 'no-port-forwarding', etc. etc. that should not be under the user's control )
We have historically used the LPK patch to OpenSSH, and we are transitioning to the AuthorizedKeysCommand feature, and have the two configurations above on all our production servers. Before the LPK patch, it was a non-trivial effort to add new users. I guess these days, puppet or chef would be other options too.
Just OpenSSH with either the LPK patch, or the AuthorizedKeysCommand patch, or OpenSSH 6.2 or later.
I have been using ssh keys in LDAP since 2004, with OpenLDAP. FreeIPA, and its dependency on 389/RHDS (specific, non-standard features of 389/RHDS have been built into IPA, whereas many other web interfaces for LDAP have solutions to the same problems which don't rely on proprietary RHDS features) is unnecessary.
That's just what I was looking for! Now if I want to write a cross-platform application I not only need to develop for OS X, Windows XP/Vista/7 and Windows 8/Metro, GNU/Linux and the mobile OSes iOS, Android, and Windows RT, I also should develop my apps for ChromeOS, FirefoxOS, WebOS, and last but not least "Jolla."
You can develop for all of those platforms with the toolkit that is native to Jolla, Qt.
In South Africa, if you claim for a stolen phone, the insurance company will request the IMEI as part of their claim processing, and they will have the IMEI blacklisted on a database shared by all the local mobile operators.
Why don't people just tell their browser to remember their login/pwd information? That's what I do for Slashdot, BoingBoing, fb, lj, gmail, etc.
Bank websites and credit card websites, I still store the passwords in my noggin, but social media? I don't care if someone who's stolen my laptop suddenly can make twitter posts in my name.
Are you saying that it is impossible for anyone to use the information in your fb and gmail account to compromise your bank website account?
One is that you are using company resources for non-business purposes.
By the same token, I shouldn't be expected to use non-company resources (ADSL line for remote standby support, personal smartphone reading company mail) for business purposes.
Or we can come to a compromise, and all be adults.
But it got nowhere near the kind of marketing Lumia has had. Not even the N9 had anything close to what Lumia is getting (and it wasn't even sold in most first world countries), yet it made similar sales numbers.
/me raises hand... I still can't settle on anything that would suit me better than my N900.
My wife and I didn't pirate it, but did finally purchase the entire first season when it appeared on iTunes. This gave us good quality, and commercial free. For a hell of a lot less money than cable and HBO runs in our area. But, now here's of course why so many pirate instead.... we had to wait over a year to -PAY- HBO for the show. If we'd been in any rush to see it
Or, if you lived in a different country, where Apple does not have rights to distribute it
we would have had no choice except to pirate it.
Note that in most other countries (outside North America, and possibly the UK), there is *no* legal way to download TV shows. No TV shows on iTunes. No Netflix, no Hulu, no content available on Amazon.
You would think the production houses would have figured out that the same technology which allows a few people to distribute large content to millions of people around the world for very low costs would allow them to reach their customers directly, without many different 'distribution' companies, license agreements, thousands of lawyers (or the Apple 30% tax), and allow them to both serve the customers better, understand what the customers are prepared to pay for, all allowing them to make more money.
Why don't they just run private trackers and RSS feeds with subscriptions available per-season, in the $1 to $3 per show range?
In Linux I can type in anywhere: ssh-add and it adds my ssh key for every program. Why can't it be that easy in Windows?
pageant(from PuTTY) works adequately. But, the combination of an ssh-agent and bash-completion is still difficult to achieve without actually having bash (e.g. from mingw32), and using plink (to run commands remotely once-off) and pscp are less convenient, and you lose out on all the programs that use ssh as a transport.
It makes absolutely zero sense whatsoever under any conceviable circumstances to use a third-party cert to authenticate between two parties who have already authenticated each other prior to their first communication. For example, if you are connecting your own email client to your own email server, it is ridiculously, mind-bogglingly insecure to rely on a third-party certificate to authenticate this transaction.
if the third party is your own Root CA, then it does make sense. For example, I can issue a new cert on the mail server (for whatever reason), without the users all needing to accept a self-signed cert and cultivate bad security habits.
Maybe you need to think about the 'Trusted 3rd party' a bit more, specifically comparing SSL/PKI with Kerberos. Without a trusted third party, how are you supposed to do the initial authentication you speak of? Do all your users actually check SSL certificate fingerprints every time you point them at a service using 'first party public keys' (SSL certificates are public/private, and the SSL client gets the public key during negotiation)?
Your key is compromised. So your question is how do you revoke it????
Maybe you issue a new one????
Just saying that's all......
And the old cert that someone stole is still valid, if they manage to redirect users to a system they control that has the old cert, your users will think it is the valid one, and the real one is the fake one, and you've just compromised all your users credentials.
We use Exchange Server and Microsoft Outlook for our e-mail. We use self-signed SSL certs.
You have absolutely no idea what you are talking about. [...] You can rollout your own CA, whether it is to use at home, or in Fortune 100 company.
You know there's a difference between using self-signed certs, and an internal CA, right?
(of course, all root CA certs are self-signed, intermediary CA certs are not, but the distinction being, you usually don't use the self-signed cert itself for anything but signing other certs).
Using your own internal CA (which you can either do by getting a commercial CA cert signed by a commercial root CA cert, or by creating your own self-signed CA cert) to authenticate/certify your internal services is good. Using self-signed certs to secure your services usually does nothing to authenticate the service to the end user, if they aren't verifying the cert fingerprints via some other method.
Why are these simple concepts so hard to understand for most people - I will never understand.
Well, in actual fact, nothing prevents software from allowing the user more control of validation of certificates. For example, nothing is stopping software from storing the fingerprints, and notifying the user when the fingerprint has changed, even for certificates signed by a trusted CA. It would be useful to be able to assign a trust level to an individual CA certificate.
But, you understood that all, right? A self-signed cert has less about it that you can validate automatically than a commercially signed cert. Everything you can validate about the self-signed cert can be validated on a commercial cert.
(In our environment, where we are responsible for 200 servers with about 50 internal users, > 5000 users inside the company, plus customers, we use an internal self-signed CA cert for all internal services such as VPNs, most internal web admin interfaces, and commercial certs for customer-facing interfaces).
Nokia specifically made provision for this, there is 'open mode', you can flash kernels onto the device, they need some patches to disable the security framework if you want to boot Harmattan (and you may lose some functionality that is protected by Aegis), and while you have a non-Nokia kernel running, you will see a nasty warning when you boot the phone.
But, you can easily install (multi-boot) other distributions.
Really, how do you think mer / Nemo and Nitdroid (Android 4.0.3)runon the N9 ? Since Nokia did things right with the N9 (upstreaming as much as possible), the Nitdroid team has almost full functionality available (calls, 3G, USSD, bluetooth, wifi etc.), where on the N900 years of work by the same team and they didn't manage to get calls or 3G working (though I think mer on the N900 does).
Slashdot Mirror
It'swould be more like Cisco requiring ypu to buy a software/feature licence to use 10Gbps ports on hardware you already paid for.
Oh wait, they do that already (e.g. on ASA-5585-X, probably other ASA nodels too)
1) You can use a different logger with systemd
2)To watch log messages with journal, journalctl -f
There are still some things I don't like about the journal (I haven't seen how to specify different retention rules for logs of different applications), but then I've only spent a few minutes actively using it.
Maybe the thing that irritates me about journal is I don't know what previously unsolved problem it is trying to solve, while making some log processing difficult.
But, if you are booting from CDs, and the CD has the rest of the media, why do you need the utility for verifying signatures on the boot media (1.44MB image)? Bootstrap the installation image from the iso9660 part of the CD (or network in the case if a network install)? and have that contain the signature verification utility.
Hint: RPM-baswd distro have been doing this since rpm 3.x, or about 1999.
Really, who uses floppies for installation these days? Sure, maybe floppy emulation on a DRAC or iLO or ILOM, but they all
-support CDROM or DVD emulation
-PXE boot (with relatively large images possible via TFTP)
If none of these are options, just write the whole (hybrid) ISO image to a 4GB USB flash disk and be done with it.
I personally haven't used an actual CD-RW or DVD to install a syatem in about 5 years. Either network install booted via PXE for servers, or USB flash disk for laptops.
I am on Android, and I don't see any way to see the video from m.slashdot.org.
Oh, and that still doesn't answer why laptops are trickier than desktops in this regard.
Unless your boot is "Please enter password to boot up computer" before it can boot the OS.
Of course it is. Any other FDE is the sprinkling of magic encryption dust kind of FDE. Both initscripts (on RH-style systems) and systemd support this, and have for years.
c) full-disk encryption can be tricky to do right on laptops, which are the main user of WiFi.
Why?
I have been using full (or, full enough, /boot isn't encrypted) disk encryption on my laptops for years. Since my only non-laptop is a workstation in a secure facility, I only did full disk encryption on that a few months after first doing it on my laptop (which is a much bigger security risk than my workstation).
I have used KDE for a long time. My laptop has an embedded 3G card that works better / more easily with NetworkManager/ModemManager than with more traditional (e.g. pppd, wvdial etc.) setups. Thus, I tried KNetworkManager.
However, I use WiFi networks with both WPA2 Personal, and WPA2 Enterprise, security. I don't mind my WiFi keys for the WPA2 Personal networks being stored somewhere, but I don't want my passwords for WPA2 Enterprise networks stored *anywhere*. Before trying NetworkManager/KNetworkManager, I would have all the WiFi configuration in /etc/wpa_supplicant.conf except the username and password, and run wpa_gui. The first time a specific instance of wpa_supplicant connected to said WiFi network, wpa_gui would pop up a dialog prompting for username and password, and I wouldn't need to enter the same credentials for the lifetime of that wpa_supplicant process (typically longer than the lifetime of the password).
However, with KNetworkManager, my options are:
-Store
-Always Ask
In the 'Store' case, due to my KDE Wallet settings (including 'close when screensaver starts'), now every time I resume my laptop, I will be prompted to enter my KDE wallet password (longer/more complex than the WPA Enterprise password).
In the 'Always Ask' case, I am required to enter my password *every* *time* I associate to the the SSID.
So, maybe it is better than nm-applet (I haven't used nm-applet *that* much) or the Gnome 3 integration (which I only see when trying to help a colleague), but it most definitely isn't better than the old /etc/sysconfig/network-scripts in conjunction with wpa_supplicant approach that I have been using for the past 7 years. On Mandriva (and Mageia), the net_applet tool can do all that configuration anyway, so there really doesn't seem to be any benefit. Of course, systemd will most likely require NetworkManager only at some point. I hope someone fixes NetworkManager to be more sane before then.
At present, I don't care about having a WiFi network connected before a user is logged in. Surely on a typical laptop, that occurs once a month or so? We have network authentication with cached crendentials, and I can kinit after logging in anyway. If this is really a requirement, using TPM (with all of its failings) would probably be a better approach.
And all platforms that support EAP support PEAP with MSCHAPv2.
Any network that does PEAP with MSCHAPv2 using credentials thay are usee dor any other service is vulnerable, unless the clients will require certificates signed by a trusted CS cert.
Android authenticating via FreeRADIUS to Samba password hashes to allow access to an AP running OpenWRY would be vulnerable by default.
EAP is performed when the EAP client is trying to establish layer 2 connectivity, before IP address aasignment can happed. Since there is no IP, there is no way to do a DNS lookup, and nothing to validate the subject cn against.
If certificate validation against CA certificates is disabled by default ( which is the case on Android as well), certificate validation collapses to whether the cert has expired.
I am only aware of 2 mobile platforms that do this better, iOS which prompts on a new EAP certificate, and Symbian, which didn't allow connecting to EAP networks with certs not signed by a trusted cert.
The recent 'it just works' race to the least secure is not going to end well.
If it were me, I would:
For example, in a container format that supports separate streams and meta-data, store an x.509 certificate or PGP signature by a licensing representative of the artist of the content's digest/hash and the customer's details (e.g. name).
Have playback/display software show the content that has such a signature differently, e.g. a badge with the customer's details from the signature.
Allow a user who has copied the content from someone else to buy just a license for the content, and all you need to do is:
Of course, some changes to media consumption software would be required to support this model.
I would definitely be motivated to license more of the works I have copied if it was easy, didn't require downloading new versions, and had something more attractive to me. There is currently almost nothing to distinguish works I have paid for from ones I haven't (except that I store them separately). For most users, the only distinguishing factor is that the one they haven't paid for is easier to use.
Cluebats welcome.
I'm wondering what's wrong with "scp -rp ~/.ssh user@host:~/" (assuming pword auth can be enabled momentarily).
1)PasswordAuthentication no
(One of the reasons to use keys is to avoid password cracking, and/or enforce two-factor/multi-factor authentication/authorizaion in conjunction with sudo or a VPN or similar)
2)AuthorizedKeysFile /etc/ssh/keys/%u.pub
(Many security frameworks don't allow non-administrative users to have full control over keys, as this can lead to abuse, such as a member of the dba group, who can run certain commands as the oracle user with auditing, giving him/herself unrestricted/unaudited access to the oracle user account. Another example is if there are restrictions in the aurhorized keys entry, such as forced command, or sources that can use the key via 'from', 'no-port-forwarding', etc. etc. that should not be under the user's control )
We have historically used the LPK patch to OpenSSH, and we are transitioning to the AuthorizedKeysCommand feature, and have the two configurations above on all our production servers. Before the LPK patch, it was a non-trivial effort to add new users. I guess these days, puppet or chef would be other options too.
FreeIPA and SSSD are not required.
Just OpenSSH with either the LPK patch, or the AuthorizedKeysCommand patch, or OpenSSH 6.2 or later.
I have been using ssh keys in LDAP since 2004, with OpenLDAP. FreeIPA, and its dependency on 389/RHDS (specific, non-standard features of 389/RHDS have been built into IPA, whereas many other web interfaces for LDAP have solutions to the same problems which don't rely on proprietary RHDS features) is unnecessary.
That's just what I was looking for! Now if I want to write a cross-platform application I not only need to develop for OS X, Windows XP/Vista/7 and Windows 8/Metro, GNU/Linux and the mobile OSes iOS, Android, and Windows RT, I also should develop my apps for ChromeOS, FirefoxOS, WebOS, and last but not least "Jolla."
You can develop for all of those platforms with the toolkit that is native to Jolla, Qt.
You'll still have issues with app stores though.
In South Africa, if you claim for a stolen phone, the insurance company will request the IMEI as part of their claim processing, and they will have the IMEI blacklisted on a database shared by all the local mobile operators.
Why don't people just tell their browser to remember their login/pwd information? That's what I do for Slashdot, BoingBoing, fb, lj, gmail, etc.
Bank websites and credit card websites, I still store the passwords in my noggin, but social media? I don't care if someone who's stolen my laptop suddenly can make twitter posts in my name.
Are you saying that it is impossible for anyone to use the information in your fb and gmail account to compromise your bank website account?
One is that you are using company resources for non-business purposes.
By the same token, I shouldn't be expected to use non-company resources (ADSL line for remote standby support, personal smartphone reading company mail) for business purposes.
Or we can come to a compromise, and all be adults.
But it got nowhere near the kind of marketing Lumia has had. Not even the N9 had anything close to what Lumia is getting (and it wasn't even sold in most first world countries), yet it made similar sales numbers.
My wife and I didn't pirate it, but did finally purchase the entire first season when it appeared on iTunes. This gave us good quality, and commercial free. For a hell of a lot less money than cable and HBO runs in our area. But, now here's of course why so many pirate instead.... we had to wait over a year to -PAY- HBO for the show. If we'd been in any rush to see it
Or, if you lived in a different country, where Apple does not have rights to distribute it
we would have had no choice except to pirate it.
Note that in most other countries (outside North America, and possibly the UK), there is *no* legal way to download TV shows. No TV shows on iTunes. No Netflix, no Hulu, no content available on Amazon.
You would think the production houses would have figured out that the same technology which allows a few people to distribute large content to millions of people around the world for very low costs would allow them to reach their customers directly, without many different 'distribution' companies, license agreements, thousands of lawyers (or the Apple 30% tax), and allow them to both serve the customers better, understand what the customers are prepared to pay for, all allowing them to make more money.
Why don't they just run private trackers and RSS feeds with subscriptions available per-season, in the $1 to $3 per show range?
Or rsnapshot
In Linux I can type in anywhere: ssh-add and it adds my ssh key for every program. Why can't it be that easy in Windows?
pageant(from PuTTY) works adequately. But, the combination of an ssh-agent and bash-completion is still difficult to achieve without actually having bash (e.g. from mingw32), and using plink (to run commands remotely once-off) and pscp are less convenient, and you lose out on all the programs that use ssh as a transport.
It makes absolutely zero sense whatsoever under any conceviable circumstances to use a third-party cert to authenticate between two parties who have already authenticated each other prior to their first communication. For example, if you are connecting your own email client to your own email server, it is ridiculously, mind-bogglingly insecure to rely on a third-party certificate to authenticate this transaction.
if the third party is your own Root CA, then it does make sense. For example, I can issue a new cert on the mail server (for whatever reason), without the users all needing to accept a self-signed cert and cultivate bad security habits.
Maybe you need to think about the 'Trusted 3rd party' a bit more, specifically comparing SSL/PKI with Kerberos. Without a trusted third party, how are you supposed to do the initial authentication you speak of? Do all your users actually check SSL certificate fingerprints every time you point them at a service using 'first party public keys' (SSL certificates are public/private, and the SSL client gets the public key during negotiation)?
Your key is compromised. So your question is how do you revoke it????
Maybe you issue a new one????
Just saying that's all......
And the old cert that someone stole is still valid, if they manage to redirect users to a system they control that has the old cert, your users will think it is the valid one, and the real one is the fake one, and you've just compromised all your users credentials.
I hope you don't store any personal data.
We use Exchange Server and Microsoft Outlook for our e-mail. We use self-signed SSL certs.
You have absolutely no idea what you are talking about.
[...]
You can rollout your own CA, whether it is to use at home, or in Fortune 100 company.
You know there's a difference between using self-signed certs, and an internal CA, right?
(of course, all root CA certs are self-signed, intermediary CA certs are not, but the distinction being, you usually don't use the self-signed cert itself for anything but signing other certs).
Using your own internal CA (which you can either do by getting a commercial CA cert signed by a commercial root CA cert, or by creating your own self-signed CA cert) to authenticate/certify your internal services is good. Using self-signed certs to secure your services usually does nothing to authenticate the service to the end user, if they aren't verifying the cert fingerprints via some other method.
Why are these simple concepts so hard to understand for most people - I will never understand.
Well, in actual fact, nothing prevents software from allowing the user more control of validation of certificates. For example, nothing is stopping software from storing the fingerprints, and notifying the user when the fingerprint has changed, even for certificates signed by a trusted CA. It would be useful to be able to assign a trust level to an individual CA certificate.
But, you understood that all, right? A self-signed cert has less about it that you can validate automatically than a commercially signed cert. Everything you can validate about the self-signed cert can be validated on a commercial cert.
(In our environment, where we are responsible for 200 servers with about 50 internal users, > 5000 users inside the company, plus customers, we use an internal self-signed CA cert for all internal services such as VPNs, most internal web admin interfaces, and commercial certs for customer-facing interfaces).
you can't ... replace the kernel
Nokia specifically made provision for this, there is 'open mode', you can flash kernels onto the device, they need some patches to disable the security framework if you want to boot Harmattan (and you may lose some functionality that is protected by Aegis), and while you have a non-Nokia kernel running, you will see a nasty warning when you boot the phone.
But, you can easily install (multi-boot) other distributions.
Really, how do you think mer / Nemo and Nitdroid (Android 4.0.3) run on the N9 ? Since Nokia did things right with the N9 (upstreaming as much as possible), the Nitdroid team has almost full functionality available (calls, 3G, USSD, bluetooth, wifi etc.), where on the N900 years of work by the same team and they didn't manage to get calls or 3G working (though I think mer on the N900 does).