Archive for October, 2007

Diner, petnames, misc

Tuesday, October 30th, 2007

Ok, as it has been a while since I last posted and will probably be some time until I next post, lets do two posts in one day. This one is just some miscellaneous items.

-

(Thats “diner” in the title, not “dining cryptographers and their problems”…)

I rarely talk about customer service with regards to places to eat. The main reason for that is I generally eat in my local neighborhood, and I learned a while back that talking about places you can be found reliably on a blog is not always the smartest thing to do.

That said, there is one diner in Manhattan that I make a point of swinging by quite often, namely Cheyenne Diner. Great customer service, including my absolute favorite waitress in Manhattan (I don’t think I have actually had to order for myself in over a year – my food just appears). Quality food and lots of it on the cheap. Open 24 hours, so perfect for a late night person (like me). Just an all around great experience.

Anyway, while I think I may be the only NY resident that absolutely loves this place, at least someone else has noticed it. (Unfortunately, the articles at the referenced site do not have separate links. Perhaps this will end up being the archive page for this month.)

On the block: Top 10 New York Classic Diners, a list of the best New York diners that haven’t changed much at all (including prices, interiors, and staff) in the last 20+ years. What you pay for one drink at some new fancy bar will get you a full meal (with bread, salad, and a side, of course!) at most of these places.

[...]
9. Cheyenne (Midtown West)

It is on the corner of 33rd st and 9th ave, a few blocks from Penn station (for those of us coming from, say Bayside :) ). Being smack dab in the middle of mid-town, you find locals, commuters, and tourists alike pop in.

Needless to say, highly recommended. I always end up there some time well into the nightshift, and I can’t say enough good things about the late night staff.

-

This is a petnames plugin for Firefox. [recently resurfaced in this mailing list post]

It reminded me of an old post. I pointed out using your bookmarks and commented on an SSH style of bookmark where public keys (in certificates) were part of it. I also noted that such a thing might not mean anything to average end users over a regular bookmark, which was the tricky part.

Attacks based on user ignorance of anything to do with PKI or TLS will apply regardless of “high assurance” certificates or not. What really matters here is whether or not browser security indicators matter to users (e.g., do users know about the security indicators provided by a browser, what the indicators mean, and what should be done in response to the indicators?).

    […]verifying that you are in fact establishing an SSL/TLS session with the proper entity.[…]
    […]countering an SSL/TLS MITM attack.[…]
    This is an active research area. Petnames have been proposed, which I like (think PGP web of trust in some form). This has similarities to the SSH-type trust model, which has also been proposed and which I also like. In recent minutes to an IETF-PKIX meeting, the Opera people were looking at “extended validation” certificates. There has been all sorts of talk, pros and cons, about “high-assurance” certificates.

In this regard, while I like the idea of bookmarking a web site and its certificate(s), how exactly to inform a user that a certificate is changed, and establishing what actions a user should take in such a case, is the hard part. Every model I envision reduces to checking the digital certificates when the certificate presented is different from the one that is bookmarked, and then all the same problems come back into play – you might as well have just bookmarked the web site and left out the certificate.

So, I like the petnames plugin for Firefox, and I think most people familiar with the SSH way of doing things would be comfortable here. The plugin adds another layer to the advice provided here, and works well for me at least.

Bookmark web sites that you visit, especially where you conduct transactions like buying stuff, and then return to those sites only through your bookmarks (this is like what we do with server public keys in SSH). Now, when you receive that email, instant message, or embedded link in some rogue web site purporting to be from, or purporting to point you to, Paypal and you really do feel it necessary to log into Paypal in response, don’t follow any of the links provided – instead, use your bookmark for the Paypal web site. It doesn’t solve all these problems, but it helps quite a bit.

-

But, it looked real… [via the gold-silver-crypto mailing list]

Evidently, no one at Minnesota-based Supervalu bothered to confirm the authenticity of emails sent in late February. Purporting to come from two of the company’s suppliers, the messages instructed Supervalu to wire all future payments to new bank accounts. One email purported to come from representatives of Frito-Lay and the other from American Greetings. Both suppliers have established relationships with the grocery chain.

The emails were phony, but within two days, Supervalu began moving money into the accounts. Over the course of a week, the company transferred $10,128941.94 in nine separate payments. [...]

These kids have become my standard quote for this.

Teen #1: Hey, man, I think we should get our important stuff laminated. No one ever questions lamination.

-

Short article (behind a paywall) about talking tech to the non-techie.

Technology is very complex and intimidating, and technology folks are constantly getting knocked for poor communication and poor customer-service skills. It’s taking a lot of time, leads to a lot of frustration, and leads to a lot of money being misspent.

This brought to mind one of the core reasons I originally founded D-kriptik and the original point of this blog – bridging tech and non-techies. Customer service is still at our core, but we have wandered a bit off the general IT support course.

-

Perhaps its the Trek in me, but this reminded me of transparent aluminum.

By mimicking a brick-and-mortar molecular structure found in seashells, University of Michigan researchers created a composite plastic that’s as strong as steel but lighter and transparent.

Updating to FreeBSD 7 Beta 1 from FreeBSD 6.2

Tuesday, October 30th, 2007

At some point, I saw this.

The 7.0-BETA1 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag.[...]

So, updating a few “play” systems here from FreeBSD 6.2 to FreeBSD 7.0 Beta 1 was pretty much a piece of cake.

I did something along this lines of…

  • create a new custom kernel config (based on my old one)

    e.g.,
    cp /usr/src/sys/i386/conf/GENERIC /usr/mykernconf7
    vi /usr/mykernconf7 and modify as desired
    ln -s /usr/mykernconf7 /usr/src/sys/i386/conf/mykernconf7

  • update /usr/stable-supfile to point to RELENG_7

    e.g.,
    vi /usr/stable-supfile and change to the relevant line to something like “*default release=cvs tag=RELENG_7″

  • cd /usr/src
  • cvsup -g -L 2 ../stable-supfile
  • make buildworld
  • make kernel KERNCONF=mykernconf7
  • reboot (to single user mode)
  • cd /usr/src
  • mergemaster -p
  • make installworld
  • mergemaster
  • reboot

…to upgrade the base OS.

With FreeBSD 7 Beta 1 running, I thought it would then be useful to rebuild all of my ports.

First, I updated my ports tree and grabbed the new index (for “make search” and “portupgrade” purposes).

  • cd /usr/ports
  • cvsup -g -L 2 ../ports-supfile
  • make fetchindex

Next, I rebuilt ruby and then portupgrade. (Note: I generally perform a “make” by itself rather than just a “make deinstall” followed by a “make reinstall” so that I can verify the port does indeed build before removing the prior installation of the port.)

  • cd /usr/ports/lang/ruby18
  • make clean
  • make
  • make deinstall
  • make reinstall
  • make clean

When using a portupgrade configured with ruby-bdb to interface with the pkgdb.db, I then reinstalled ruby-bdb.

  • cd /usr/ports/databases/ruby-bdb
  • make clean; make
  • make deinstall;make reinstall;make clean

Otherwise, portupgrade was still configured to use ruby-bdb1 to interface with the pkgdb.db, so I deinstalled ruby-bdb1. I did not reinstall ruby-bdb1 directly, as portupgrade would fail to reinstall if I had (when portupgrade is configured to use ruby-bdb1, it always attempts to reinstall ruby-bdb1, even if ruby-bdb1 is already installed).

  • cd /usr/ports/databases/ruby-bdb1
  • make clean; make deinstall

And finally for portupgrade,

  • cd /usr/ports/ports-mgmt/portupgrade
  • make clean; make
  • make deinstall;make reinstall;make clean
  • pkgdb -F

Next, as is my normal practice when building ports, I looked in “/usr/ports/UPDATING” to see if there were any tricky port upgrades since my last update. Some places, I had Gnome installed, and it turned out that updating to Gnome 2.20.1 swapped in rarian for scrollkeeper, so I followed the steps in “/usr/ports/UPDATING”.

  • portupgrade -f -o textproc/rarian textproc/scrollkeeper

Ok, that being the only trickiness since my last port update, I proceeded to rebuild every installed port.

  • portupgrade -fa

Yes, that took quite a while.

After using the functionality of this machine I normally use and running stably for a bit, I cleaned up my ports.

  • portsclean -CDL

So, the system seems to be stable, although I have not done anything that punishes it as yet, beyond rebuilding all the ports.

A few notes, not necessarily FreeBSD 7 related:

  1. Running “ndisgen” under FreeBSD 7 had trouble on a driver where it had worked fine under FreeBSD 6. When I used an interactive run of ndisgen where the inf and sys file names were entered when prompted, the ko generation failed. However, when I entered the inf and sys file names as commandline options worked, the ko generation succeeded, and the resulting kernel module worked fine.)
  2. Portupgrade was changed to use ruby-bdb by default a while ago. If you are still using ruby-bdb1, now might be the time to switch to ruby-bdb. This is somewhat trivial to do, and the following will rebuild portupgrade and its database for ruby-bdb.
    • cd /usr/ports/ports-mgmt/portupgrade
    • make config
      (select the ruby-bdb option and deselect the ruby-bdb1 option)
    • make clean; make
    • make deinstall; make reinstall
    • cp /var/db/pkg/pkgdb.db /var/db/pkgdb/pkgdb.db.bdb1
    • pkgdb -fu

    The following updates the ports index database. For FreeBSD 7, this is “/usr/ports/INDEX-7.db”, which is used below.

    • cd /usr/ports
    • mv INDEX-7.db INDEX-7.db.bdb1
    • portsdb -u
      or,
      portsdb -Fu
      if you do not already have an up to date ports index.

  3. If you find, at the end of a “portupgrade -fa” run, that some ports failed to be rebuilt, it can be quite annoying.

    If this list of failed ports is quite large, often it is due to a few key ports failing to build, and then all ports dependent on those key ports being skipped. By fixing whatever issues arose with those key ports during building and getting them to build, you can then get all the skipped ports to build.

    After fixing all key ports, you could then use portupgrade to rebuild all ports dependent on those key ports (e.g., “portupgrade -r <port name>”); however, this can be painful if a number of key ports failed, especially with layered dependencies (e.g., one failed port causes another port to be skipped, but this skipped port is a dependency of another port causing that other port to be skipped, and so on). This is especially so given a “portupgrade -fa” on a large base of installed ports. So, I found it much easier to just rebuild all ports not installed after a particular date, with the particular date being the day before I began the original “portupgrade -fa”.

    For example, say we began out “portupgrade -fa” on October 30, 2007. It wrapped up, and we found a few ports failed to build successfully and a bunch of other ports were skipped because of this. So, we go in a fix the few ports that failed causing the other ports to be skipped. After that, we can run something like the following to rebuild all ports installed prior to October 30, 2007, which would map to all the ports that failed during our “portupgrade -fa” started on 2007-10-30.

    • portupgrade -f ‘<2007-10-30′