Dialectronics - the dialect of electronic communications




About Us

Our Mission

Minix

RISCV

PowerPC

Lua

XCOFF Bootloader

Old World Macs

Open Firmware

Words

Journeys

Home Repair

Top Level

Recent News:

1/31/24: You can see where we are migrating to at the M. J. Janson Institute of Analytical Medicine

11/8/22: There's new information about the code used to generate the performance analysis between FreeBSD and Minix 3.1.6. It used genome profiles of different pathogens to find matches. Results are discussed.

11/7/22: We've posted some patches to the PowerPC C backend for the Portable C Compiler; these fix stack frame calculations, parameter overflow location on the stack, and incorrect definitions for r0 and r2.

11/3/22: We've made a couple new posts about the RISC-V32 C backend for the Portable C Compiler; two patches to fix a bug in pcc's optimization code and an update to the code to eliminate a problem with unnecessary register moves.

10/25/22: We've released an alpha version of a RISC-V32 C backend for the Portable C Compiler

10/25/22: We released our backport of the the Minix 3.1.6 AHCI driver code, to run a SATA drive. We have been using it on a dual-SSD (mirrored) drive on Udoo x86 Advanced for some time. However, if vfs fails, ahci will keep writing, regardless of where it is. This has resulted in overwrites of existing files with error messages destined for /usr/log/messages.

7/23/18: We released the Minix 3.1.6 rtl8111 driver code, to run the RealTek 8168/8111G ethernet chip on Udoo x86. It is three files, and the links are on the Minix page.
7/16/18: Wow! Ten years since we last updated this page! We've been busy. We'll be opening a new section soon, Minix, as we've been spending a lot (A LOT!) of time working with Minix 3.1.6. A couple quick tidbits: one, to fix the e1000 driver for Minix 3.1.6 in VirtualBox, make sure the driver has pci bus mastering enabled, two, Minix 3.1.6 runs on Udoo x86 with some tweaking of the boot process, and three, we'll be releasing an rtl8111 driver for Minix on Udoo, to run the RealTek 8111G ethernet chip. All three work great in-house.
1/2/08: A New Year. Here's hoping it will be less strange than the previous one.

We are in the process of porting QZ! Engine away from 4D (14,250+ lines of code), which is why we pulled discussions about it. The new version will be QZ! Engine 2.0, and is projected to run on a PHP/PostgreSQL/Lighttpd combination. We're going to try to support other C-like scripting languages. Lua support may be possible, but our focus is on more mainstream scripting languages for this first port.

One thing we immediately ran into with PHP and PostgreSQL is that userid and passwords get stored in plain text in PHP scripts, unless the user provides them through a web interface. Since we have a need of authentication outside of PostgreSQL accounts (QZ! Engine self-hosts the accounts), and we do not like leaving passwords unencrypted, we decided to tackle this issue in PostgreSQL. It turned out to be rather straightforward to alter libpq to let clients submit passwords that had already been encrypted via MD5, rather than having to accept them as plain text. The functionality is already present, so it was a matter of adding two lines of code to src/interfaces/libpq/fe-auth.c.

The first thing to understand is the method by which PostgreSQL encrypts the password. It actually encrypts the password twice. The first time salts the plain text password with the user's id, adding it to the end of the password. The second time takes the encrypted text (minus the "md5" prefix the PostgreSQL encryption code adds) and salts it with a "per-connection" salt. The first encryption can be skipped; the second can not.

Here's the altered code (should be around line 414, in pg_password_sendauth with commit message dated v 1.121.2.2 2007/07/23 18:13:09):

                                /* if already presented as postgresql-ified MD5, leave alone */
                                if (isMD5(password)) {
                                        crypt_pwd2 = (char *) password;
                                }
                                 
                                else {
                                        crypt_pwd2 = crypt_pwd + MD5_PASSWD_LEN + 1;
                                        if (!pg_md5_encrypt(password, conn->pguser, 
                                                                        strlen(conn->pguser), crypt_pwd2))
                                        {
                                                free(crypt_pwd);
                                                return STATUS_ERROR;
                                        }
                                }

(Here's a diff for v.1.136)

The "isMD5" call is actually a macro that simply checks that the first three characters are "md5" and that the length of the string is correct. If the string of characters presented has these conditions, salting the password with the user id is skipped. Alter the code as above, recompile PostgreSQL and anything that links against libpg (like php-cgi) and you're ready to go. You don't even have to change the passwords in PostgreSQL.

This leaves the second part to understand to the PHP side of things. There are now two ways to store your passwords. You can leave them plain text, or you can encrypt them manually and then store that encrypted string for presentation to connecting to PostgreSQL. You have to follow the first step above, though, and append the user account string to the end of the password before running the combined string through md5(), and then _prepend_ "md5" to the resulting hash. That full 35 character string is what you present in pg_connect for the password field.

Syntactically:
1) $mystr = 'mypassword' . 'myaccount';
2) $enc = md5($mystr);
3) $enc = "md5" . $enc;

In an included file (shadow.inc)
4) $enc = 'result from above';

In the web apge actually connecting to the PostgreSQL database:
5) include "shadow.inc";
6) $conn = pg_connect("dbname='mydb' user='myaccount' password=$enc");

The advantage to this approach is that you can enter the raw password in the psql command line client while being able to store the encrypted password in a file. You can also enter that 35 character string as the password as well. Note that if you use authentication through something other than md5, you will need to use the plain text. Also note that this provides absolutely zero additional authentication security. The only benefit is that the original, raw password is not stored in plain text, and will be difficult to recover (since the salt is known, it is vulnerable to being reversed through lookups).

Now, if you're willing to sacrifice being able to log in with a plain text password entered into the command line client, you can take this one step farther and choose your _own_ initial salt (or not salt at all). In the PostgreSQL superuser, enter the encrypted string when creating or altering the role:

ALTER ROLE useraccount WITH ENCRYPTED PASSWORD 'md5prefixedencryptedstring';

If you use the default salt approach (user id appended to the end of the password), you can enter the password unencrypted when creating or altering the role's password, and enter the password in plain text from the command line or enter it with "md5" prefixed to the 32 character string, and present it in plain text or encrypted via PHP. The flipside is that if the user account is known, so is the salt. If you use your own salt, you have to accept not being able to log in as that specific user unless you paste the full 35 character string, but in return can store the encrypted password in a file with high confidence that the raw password will not be extracted. An added layer would be to make that file read-write only for the php-cgi process owner (which has no shell access) and no one else.

We are now able to connect to the PostgreSQL database using the php-cgi process owner, and authenticate with a PostgreSQL account, to check if the account coming in is listed within the QZ! Engine database, with no unencrypted passwords anywhere.
7/6/07: We've opened a new section - Lua Corner. Over there you'll find Lua-based bitwise operator code, ready to be added to your project. A lot of our development is being moved to Lua, as it provides an excellent environment to work in. We hope to make an announcement soon on some MIT-licensed tools we have been developing (to replace GPL'd ones).
6/17/07: Since there's been some interest in Beginning Open Firmware Debugging Techniques, Part I, we decided to go ahead and post Beginning Open Firmware Debugging Techniques, Part II, although in some places it is a bit rough. Better to at least get the information out there rather than let it sit somewhere unavailable to someone that might gain from it. If you wish to help polish either piece, drop us a line.
6/5/07: We're baaaaack :-) We came to realize that we can ignore our spots but that doesn't make them go away. What's new? OpenBSD finally caught up to us (after two years) and started supporting Old World Macs. We've seen a noticeable increase in traffic since then (and noted to ourselves the connections from Calgary during the 2006 hackathon).

We have decided to take the plunge and develop our own operating system, based on exokernel design. The focus will be RISC-based CPUs, with initial development on PowerPCs (Old World Macs, of course). If this wasn't difficult enough, we have decided to do it with end-to-end MIT/BSD/public domain licensed source code, including the compiler. To add to the workload, we also decided to develop a programming language that inherently optimizes RISC-based CPUs, through a register-centric mentality instead of the common stack-centric philosophy. We're looking for four or five individuals that would like to participate in this project. Applicants must have strong left-wing beliefs, be willing to accept decisions made (with or without debate) by a central authority, and have a desire to do something completely different in a world where homogeneity is not only expected but imposed (by force if necessary). Programming experience is not a prerequisite (it might even be a hindrance), but a commitment to excellence is. If this sounds like something you are interested in, drop tim an email describing your beliefs and experiences. If you are unable to locate an email address, you probably won't fit in, due to the extensive research requirements this project will have (no disrespect intended).
1/23/07: Well, what to say? We've generally packed it in and moved on. We're preparing a closing statement, but other activities keep us too busy to spend much time on it. In general, we have left computers and moved into Green building practices. We'll post more information directing visitors to that site soon.

Otherwise, the only significant changes are moving to OS X running lighttpd (one of the few installs in the world) for web serving and postfix for mail with postgrey for anti-spam measures. Lighttpd mysteriously dies every couple of days, but otherwise the package works well (Note: this was fixed by setting kqueue in lighttpd.conf). The move to OS X was precipitated by an effort to reduce our CO2 footprint as much as possible, and the NetBSD box was redundant and underused. We're not big fans of Apple, but NetBSD's power management is very poor and the Mac mini was on all of the time anyways.

We did post the NetBSD-ready version of the PowerPC-optimized bcopy/memcpy. You can find it in the PowerPC corner.

We're quite excited about the new direction we're taking. It builds on some of our past experiences in home repair field coupled with some financial planning theories we've developed (your house is your greatest asset) and the coming revolution in Green building. We'll post more when time permits.
7/18/06: Perhaps it is the summer heat and we've gone crazy, but we've posted the first installment of the never before published "Open Firmware Debugging Techniques," which was supposed to be the intro to the unpublished "This Operating System, That Hardware" series on porting NetBSD to a JS20. Part I deals with the command line interface to Open Firmware. Enjoy.
7/7/06: Updated the bcopy/memcpy code. Turns out there was a bug in the original code that caused errors with copies of less than 4 bytes when the destination address was higher than the source address (backwards copy). We've tested a kernel compiled with the code and it works. Next up is a userland and libc build.
5/31/06: Even more amazing! tim found time to post the first three installments of the "Some Assembly Required" series that did not get published by developerWorks. They can be found in the PowerPC area. What's next, posting the first two installments to "This Operating System, That Hardware?"
5/31/06: Gee, tim found some time to gather some links to work he's done as a technical editor and as a writer. They can be found in the new Words area.
5/28/06: While he hasn't had time to fully finish it, tim has posted a faster bcopy/memcopy routine to the PowerPC section. It's about 10% faster for aligned copies and about 80% faster for unaligned copies. The main holdup for releasing it in a bcopy/memcopy form is that these routines are in the string libraries that are linked against extensively. We haven't had time to do a complete rebuild, and simply replacing the recompiled libraries led to segmentation faults (not the fault of the code but the changed linking locations).


All News



"Anything war can do, peace can do better." -- Desmond Tutu