Slashdot Mirror

ACM Technews (for those of us who get it) also has an article about this here. Hrm... Wonders idly whether that spinning noise is Einstein in his grave...

Fully verifiable is a big claim. I support OSS in every way, but I wouldn't ever claim that. How can you prove that the compiler wasn't trojaned? It's open source too? Well how about the compiler that compiled the compiler before it was self-sustaining? You'd have to trace it all the way back to whoever did the first compiler in the chain, by first compiler, I mean pure machine code. This isn't a new concept.

The bottom line is, you can never, ever have 100% security, ever. You can only get kinda close. I think in this case, paper is still the best bet, and we should forget about using technology for voting, it will inevitably make voting abuse a lot easier than it already is.

Of course, the government even goes as far as openly censoring the results of a vote they do not agree with.

• You yourself have disassembled and audited the entire system, including CPU microcode.
  
  
• You yourself have personaly programed, using only hardware (no software) that you yourself have audited, the entire system, including CPU microcode.
  

This comment gives a link to the classic Trusting trust on this subject.

Obligatory link: http://www.acm.org/classics/may96/.

This ACM classic does a great work on showing that "You can't trust code that you did not totally create yourself".

Fh

This is a nifty concept, but I remain skeptical that it would ever work in practice, at least for an open-source produce such as gcc.

Before you dismiss the possibility, why not read Thompson's lecture?

So AFAICT, the trojan would have to identify itself by looking at the structure or semantics of the source file.

Yes, he did, in very clever way, which he explains. And his trick recognizes both the compiler and login command.

After descibing the trick, he goes on to say, "First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."

Whether one could get away with this in gcc (or whatever is questionable, but at some point every compile must be done with a binary. So if the first binary on a system was trojaned, it is possible that future ones could inherit the bug.

The ACM may not be all that pervasive in every computer science department, but considering that the ACM puts on many of the industry's biggest conventions, I'd venture to say that it binds (or rather ought to bind) a good number of the programmers out there.

I would argue that Trusted Computing violates section 1.1, "Contribute to society and human well-being."

Of course, I'd say a bunch of us violate section 1.5, "Honor property rights including copyrights and patent," so it kind of makes the point moot...

Much of this has to do with CS researchers forcing the conference publishers to allow distribution of papers via personal webpages. Once you have that, the rest follows.

But in fairness, Nature is only $160/year ($100 students), which covers 52 issues. Of course, you have to put up with advertising and pay a subscription...

At a recent conference there was a paper discussing one interesting aspect of this work. They are working on defining a standard remote control markup language to allow clients to render appropriate layouts. The pdf is here.

This could be pretty cool...

Sure, there is a lot of crap out there, but there is a lot of high quality research as well.

Knuth not only writes good code, he also writes intersting code, and usually that's too time consuming for regular mortals.

I seem to remember Knuth submitting some literate programs for a pair of Jon Bentley's "Programming Pearls" columns [collected in "Literate Programming", online here and here

The latter contains Knuth's solution to an assignment by Bentley: "Given a text file and an integer k, print the k most common words in the file (and the number of occurences) in decreasing frequency."

Knuth's sumbission is a beautiful work of exposition, introducing and explaining an unusual data structure (the hash trie), and in general would not look out of place framed and hanging on the wall above one's dining table.

However, in his critique of the program, Doug McIlroy provides a solution to the problem using a simple unix pipeline that takes up less than a paragraph. McIlroy finish his critique with the following remarks:

Knuth has shown us here how to program intelligbly , but not wisely. I buy the discipline. I do not buy the result. He has fashioned a sort of industrial-strength Faverge egg - intricate, wonderfully worked, refined beyond all ordinary desires, a museum piece from the start.

Knuth not only writes good code, he also writes intersting code, and usually that's too time consuming for regular mortals.

I seem to remember Knuth submitting some literate programs for a pair of Jon Bentley's "Programming Pearls" columns [collected in "Literate Programming", online here and here

The latter contains Knuth's solution to an assignment by Bentley: "Given a text file and an integer k, print the k most common words in the file (and the number of occurences) in decreasing frequency."

Knuth's sumbission is a beautiful work of exposition, introducing and explaining an unusual data structure (the hash trie), and in general would not look out of place framed and hanging on the wall above one's dining table.

However, in his critique of the program, Doug McIlroy provides a solution to the problem using a simple unix pipeline that takes up less than a paragraph. McIlroy finish his critique with the following remarks:

Knuth has shown us here how to program intelligbly , but not wisely. I buy the discipline. I do not buy the result. He has fashioned a sort of industrial-strength Faverge egg - intricate, wonderfully worked, refined beyond all ordinary desires, a museum piece from the start.

For a project I am working on, I needed to extend CWEB to do some things Knuth hadn't thought of, and I found that excessive cleverness in the data structures made it much more difficult to extend than it should have been, so that Knuth could demonstrate clever data structures that probably add a few percent to the performance over what he could have achieved with more prosaic ones (Knuth does not document why he made these excessively clever design choices, nor whether the performance advantages they offer were significant).

Similarly, a recent thread on comp.text.tex recently asking about the extensibility of TEX produced a number of comments from those who know about how unextensible and unreusable TEX really is.

So, while I use literate programming (CWEB) to document a lot of my own code, I don't believe in all these years, that I have ever seen a good example of literate-programming that looks towards the future (refactoring, extending, reusing) as opposed to generating a fossil with that comes with a good story of its life and times.

It's on the main xpilot page, but it's worth calling out the link to The Story of Xpilot from the ACM crossroads. It's the fascinating history of the development of xpilot back in the days when most people hadn't even considered that multiplayer games could exist.

I still play xpilot today, btw, and although it can't keep up with the graphics of modern day games (or even 5 year old games) it's all about the gameplay, and it still has it there.

The world doesn't work that way. If the OS itself doesn't prevent applications from accessing any address, then someone will write the exploit by hand in assembly; if it's big, they will work on a Linux machine with gcc and put a new backend on gcc to produce code that will run on Brix. After all, if they were simply porting gcc then that's what they would do, until they had a gcc good enough to compile itself for Brix, and then move over to Brix for development and keep progressing.

The data is always encrypted on the hard drive, and is only decrypted at the cache. So steal it, remove battery, submerge in liquid nitrogen is the only way to get even a little bit of data out of it. The really cute exploit is to tunnel their challenge/response over a network of some sort (say, cell phones), and just have someone follow the legitimate user around until all the information is decrypted.

The research paper on this will be presented at ACM MobiCom 2002, the premier conference on wireless networks and such.

The data is always encrypted on the hard drive, and is only decrypted at the cache. So steal it, remove battery, submerge in liquid nitrogen is the only way to get even a little bit of data out of it. The really cute exploit is to tunnel their challenge/response over a network of some sort (say, cell phones), and just have someone follow the legitimate user around until all the information is decrypted.

The research paper on this will be presented at ACM MobiCom 2002, the premier conference on wireless networks and such.

I'm sorry, but this code does not fit with what
Dijkstra learn us, because it uses "Harmful Go To"!

If you want to respect his memory, you should write the code as:

repeat
birth;
death;
until (self = enlightened);
while (true)
nirvana;

Yeah, I saw that. Sad, losing a luminary like that.

And pointedly relevent to this discussion, since FORTRAN used to use GOTO statements for branching.

If you're considering FORTRAN, then beware the GOTO as Edsger pointed out in this classic.

Your eyes have millions of receptors. When you see something like a screen, most of them are actively processing the screen. That is HUGE bandwidth. You are used to using it because your brain is processing vision constantly, so is very accurate.

A tactile interface would rely on a few hundred receptors on a handful of fingers. (pun intended) Unless you read braile, your fingers aren't that sensitive. Your fingers aren't used to being used as a primary interface, and is therefore not that accurate.

Aural (sound) interfaces are much better because they have a significant bandwidth (not as high as vision, but better than touch) and we are used to using them. That's part of why the two most-required output interfaces are a monitor and speakers.

Input interfaces are the same. The best way we have for output is our tongue (seriously), second is our hands. So our two preferred input interfaces should logially be voice and hand. We are used to typing, and always dream of the ultimate speech-control interface. Or you could go to a tongue interface, but I wouldn't want my co-developers to share it.

So as far as User Interfaces go, I think we should strive for better GUIs that can be augmented with sound and tactile feedback.

Just some thoughts.

Recompiling the compiler doesn't do anything to rid you of trojan code/back doors. If you need to ask why, take a look at "Reflections on Trusting Trust" by Ken Thompson, and the description of a back door in the jargon file.

The short story is, that the compiler decides what to output. So you have to trust your compiler.

The reason for the recompiling of gcc is something else entirely: It is to allow the source code of gcc to rely on gcc, and to allow an optimized compiler to be created.
For additional information consult a good book on compiler writing.

Even if you compile it yourself; even if you spend months verifying the source code, you can still be compiling in some backdoor code. Check out http://www.acm.org/classics/sep95/. If your compiler binary is compromised, no amount of source code review is going to help. Your only hope is to hand assemble a compiler and use that to build your software.

Spaff is pretty well known in the Internet, but I am affraid I can't think of a major contribution to computer security from him since tripwire.

The Alphora Dataphor DAE is the first relational database management system since IBM BS12 and the QUEL version of Postgres.

It was coded for MS .Net, thus it should be readily portable to Ximian Mono or GNUs & Southern Storms DotGNU Portable.Net.

If such a potentially useful software became publicized and free software, we could have a really innovating no Marketspeak intended , probably killer application the proprietary vendors would have a hard time scrambling after.

And that with unreprochable theoretical foundations attested by the luminars of the field.

The developer failed to realize the code was licensed under the GPL and would therefore require NVIDIA to release the source code

Tsk, tsk - must have just clicked on 'OK' w/o reading the text like everyone in MS world does. But seriously, couldn't NVIDIA have just removed the GPL code and be in compliance? That's what BSD (1995 article) had to do early in the 90's to assuage whoever owned Unix at the time, remove some proprietary code. They didn't have to start all over from scratch. Did the developers forget, "There's some GPL code in there but we can't recall which part!". I'll even bet there's plenty of closed source binaries out there with code 'borrowed' from GPL stuff, as it would be very difficult to discover, was deemed worth the risk.

The only way for this to work is if the machine is connected to the Internet and the user has to respond to the ad in some way(i.e. clicking a particular button) to confirm the user is actually viewing the ad, and this is reported to a server. Otherwise you can just recompile...

Or if you wanted to be clever, do what KT did and put it in GCC...

But the whole idea is a bit silly. It certainly doesn't go against the philosophy, but what's wrong with using tech support as a business model for Linux distros?

here's a link for the google shy

Perhaps a realistic example is in order. Shape, animal, and device driver toy examples don't scale to real things that I actually encounter.

A nontrivial example won't fit here, so I'll have to refer you to Parnas's original article on the topic. Its example could still be considered trivial by today's standards, but it's far better than anything I could fit in this space. It makes no reference to OO whatsoever. In fact, it's decidedly non-OO, with modules like "circular shifter" and "alphabetizer" that are most certainly procedural abstractions.

If you want a bigger example, there's my Master's thesis work, especially my defence presentation (PowerPoint slides). I consider it a good example of a successful application of information hiding principles, and it's about 23,000 LOC, so it's big enough to be considered nontrivial. It's also OO, so it doesn't prove that OO is orthogonal to information hiding, but I feel that its success arises from information hiding more than OO (especially since it's written in C and so makes no use of inheritance).

One can show that 3rd-generation languages can code the same thing with less code and be more transportable to other platforms than assembler.

The 3rd-generation-versus-assembly is the most clear-cut case of programming language expressive power there is, and yet it's still quite hard to "prove" in any meaningful way.

Relational tables are a protocol and organizational philosophy. They allow, for example, one to get GOF-like patterns with mere formulas instead of painstaking hand-referencing needed in OOP.

These sound like the wrong questions to me. It reminds me of someone's (perhaps Dijkstra's?) story of the response he received when he recommended abolishing gotos. Someone said "ok, I'll buy that; so what do I do if I'm at this point in the program, and I want to get to that point?"

The trouble with such a question is that it has no answer. Dijkstra's argument was not that one should take existing programs and remove the gotos; rather, that programs written using only structured elements (sequencing, conditionals, loops) are more comprehensible, and don't require any gotos because there is a more elegant way to achieve the same effect. Thus, as you can see, there really is no answer to the question; the questionner's approach was fundamentally flawed.

Likewise, software organization is not done in terms of functions; rather, it is done in terms of information-hiding modules. To ask when one huge function should be split into to, or when two similar functions should be merged, indicates to me that the design might be flawed. Sometimes that's unavoidable; for instance, if you are involved in a project written by someone else. In that case, you do indeed need to make this kind of decision.

However, true modular programming does not mean taking huge lumbering hunks of code and splitting them into modules. It means writing modules using the principles of information hiding to avoid making huge lumbering hunks of code in the first place.

This, of course, is easier said than done. It's not that hard to avoid gotos, because the use of Dijkstra's structured programming techniques makes them unnecessary. In contrast, writing good modules is hard, and without superhuman foresight, some modules are bound to be pretty crummy. These will need to be rewritten in order to achieve good information hiding properties.

So, there's your answer: don't put the cart before the horse. Don't expect that someone will tell you that you need to split a function when it gets beyond X number of lines. Rather, look at the integrity of the system's modules. If I can leave you with one piece of advice, I hope it is this: design module interfaces not according to what services they provide, but what information they hide. Modules for which you can't find a succinct statement (12 words or less, with no ifs, ands, or ors) of what information they hide are poorly designed, and need an overhaul. A symptom of this may be that your functions are redundant, or too long, but the core problem is one of poor module design.

These sound like the wrong questions to me. It reminds me of someone's (perhaps Dijkstra's?) story of the response he received when he recommended abolishing gotos. Someone said "ok, I'll buy that; so what do I do if I'm at this point in the program, and I want to get to that point?"

The trouble with such a question is that it has no answer. Dijkstra's argument was not that one should take existing programs and remove the gotos; rather, that programs written using only structured elements (sequencing, conditionals, loops) are more comprehensible, and don't require any gotos because there is a more elegant way to achieve the same effect. Thus, as you can see, there really is no answer to the question; the questionner's approach was fundamentally flawed.

Likewise, software organization is not done in terms of functions; rather, it is done in terms of information-hiding modules. To ask when one huge function should be split into to, or when two similar functions should be merged, indicates to me that the design might be flawed. Sometimes that's unavoidable; for instance, if you are involved in a project written by someone else. In that case, you do indeed need to make this kind of decision.

However, true modular programming does not mean taking huge lumbering hunks of code and splitting them into modules. It means writing modules using the principles of information hiding to avoid making huge lumbering hunks of code in the first place.

This, of course, is easier said than done. It's not that hard to avoid gotos, because the use of Dijkstra's structured programming techniques makes them unnecessary. In contrast, writing good modules is hard, and without superhuman foresight, some modules are bound to be pretty crummy. These will need to be rewritten in order to achieve good information hiding properties.

So, there's your answer: don't put the cart before the horse. Don't expect that someone will tell you that you need to split a function when it gets beyond X number of lines. Rather, look at the integrity of the system's modules. If I can leave you with one piece of advice, I hope it is this: design module interfaces not according to what services they provide, but what information they hide. Modules for which you can't find a succinct statement (12 words or less, with no ifs, ands, or ors) of what information they hide are poorly designed, and need an overhaul. A symptom of this may be that your functions are redundant, or too long, but the core problem is one of poor module design.

Not really.

Well...the Dragon book for starters, as mentioned earlier. That's probably the ur-source for most of the theory behind the magic. Makes my head hurt, though.

Terence Parr's book, Practical Computer Language Recognition and Translation (out of print). His doctoral dissertation is a useful thing too (try the Purdue University library).

comp.compilers is another useful resource. It's archived at http://compilers.iecc.com.

Alan Holub's Compiler Design in C is a classic.

The ACM's SIGPLAN ("Special Interest Group On Programming Languages") and it's journal SIGPLAN Notices of the ACM are all fine resources. So is ACM Transactions on Programming Languages and Systems.

Don't forget the IEEE as well.

Not to mention Abelman and Sussman: Structure and Interpretation of Computer Programs.

The garbage collection page is a good source for information on memory management and garbage collection.

Your university's library is another good resource.

Well. That should keep you out of trouble.

Well...the Dragon book for starters, as mentioned earlier. That's probably the ur-source for most of the theory behind the magic. Makes my head hurt, though.

Terence Parr's book, Practical Computer Language Recognition and Translation (out of print). His doctoral dissertation is a useful thing too (try the Purdue University library).

comp.compilers is another useful resource. It's archived at http://compilers.iecc.com.

Alan Holub's Compiler Design in C is a classic.

The ACM's SIGPLAN ("Special Interest Group On Programming Languages") and it's journal SIGPLAN Notices of the ACM are all fine resources. So is ACM Transactions on Programming Languages and Systems.

Don't forget the IEEE as well.

Not to mention Abelman and Sussman: Structure and Interpretation of Computer Programs.

The garbage collection page is a good source for information on memory management and garbage collection.

Your university's library is another good resource.

Well. That should keep you out of trouble.

...engineering operates within the framework of the immutable laws of nature. These laws dictate the realm of engineering possibility, and engineers work by designing and constructing within the bounds of these laws. Their permanence and universality allow engineering principles, which signal the boundary of what is safely possible, to be established...
...Software engineering, on the other hand, has no fixed framework in which to operate... ...unlike the world of engineering, there are not immutable laws to violate...
...These implications reflect the mathematical nature of software, and are sympomatic of the limits of the engineering approach. As a mechanism for information computation, a piece of bug-free software is essentially a mathematical function is some system of axioms...
...In this light, the work of building software is a mathematical exercise within two distinct phases: the determination of the set of information requirements (the parameters of the function); and the creation of a mathematically rigorous function that meets these requirements...

There are already codes of ethics for software engineers. Sure, they aren't mandatory, but I subscribe to them, and I'm sure that many (if not most or all) open source developers do as well (even if unconciously).

Why not post the ethical code from a viable organization, like ACM, ISACA, or ISC2?

Dealing with this kind of ethical quandary is all too often the system administrator's job - or at least our problem - because we are point of contact. If not us, who?

So far as a code of ethics goes, I feel the ACM Code of Ethics is sufficient to the needs of a sysadmin. It's not legally binding so far as I know, even if you are an ACM member, but in the absence of upper management restraining your ethical action, it is a good method for judging when to do what.

Other than that, I can only offer one caveat to the concept of instantly informing the users. Often after a break-in, some tactical delay is required to make sure we've identified all the breakin locations. Only after we're pretty damn sure do we step in and shut things down. On private systems informing the user isn't harmful, but when the information goes out via, the hazard of an annoyed cracker deciding to break something since he's on the way out anyway is too dangerous.

Of course I'm not claiming that not informing is an option, but I think a delay of up to a full working day is not unwarranted. Long enough to tie things down.

Ethernet is not Aloha. See Measured Capacity of an Ethernet: Myths and Reality, Boggs et al.

Or even a Trojan'd compiler - which would be pretty hard to spot..

But things like Ken Thompson's compiler hack take it to another level, and would be much more difficult to catch.

I'm not sure where exactly a hack of this level could be inserted into the current environment--gcc, the linux kernel, and glibc are all probably a bit obvious at this point--but how many different programs are there out there that are depended on by lots of other programs to convert from source to a running executable?

Somebody in a below post mentions inserting a hack into an Apache module; I don't think that would be enough. It would have to be something like insert a hack into an Apache library such that, when a certain module was compiled, it was compiled with a door enabled.

Could something like that make it past the many readers out there? If so, in which projects, and how nasty would it be?

I think it could happen, but it would have to be somebody who really had something to prove, and was a Roaring BadAss like Ken Thompson was. Who doesn't think Linux could hack the linux kernel to his own benefit?

The University of Notre Dame and University of Michigan both use an AFS/Kerberos set-up for large volumes of accounts.
Notre Dame offers accounts on their Solaris/SPARC machines to every student at the university. Michigan's CAEN is also an AFS/Kerberos system for the whole College of Engineering.

MIT's Athena project is pretty interesting (and also partially uses an AFS/Kerberos scheme), but it probably won't help you set up a quick public network of Linux machines since it focuses more on the research side of things (not to mention the fact that it's been actively worked on since 1983!).

In general, you will probably want to decide between an AFS/Kerberos set-up or an NFS set-up.

With AFS/Kerberos, you as the administrator would directly control a pool of servers ("Vice") which physically contain the data in every user's account. The client machines ("Venus") would get temporary "tickets" from the central Kerberos server (which you also control) to access their accounts which are stored on Vice.
In the NFS scenario, the physical location of accounts is totally decentralized and distributed across all the machines that users actually work on. This means less work for you as an administrator, but it also means less security since random users' data is actually stored on the disks of the computers in the user pool (in AFS, Vice machines are considered to be "locked in closets" to which only the administrators have physical access). It's good to remember a golden rule, "physical access to a computer always implies root access." Using a tomsrtbt disk for example, you can change the root password on just about any Linux machine with a floppy drive.

Since Vice (in the AFS scheme) computers are presumably kept behind locked doors, you avoid this type of problem. However, AFS is harder to maintain, and you probably have to pay Transarc for a commercial version.

For more info on AFS/Kerberos and NFS, I recommend surfing the ACM Digital Library, in which you can find the seminal papers on these various technologies (if you're an ACM member and have access). You may also be able to find case studies there (which I found to be surprisingly hard to find on the web).

It's a little different from standard virus infection, but the techique could be easily modified. Here's a short description of the technique, and here's the full text of the speech (with slides).

Just take a look at this article for proof. Basically, the trojan doesn't even show up in the source code at all, but it still exists.

Are you sure you can trust your compiler? http://www.acm.org/classics/sep95/

The homograph attack in Communications of the ACM 45(2) by Evgeniy Gabrilovich and Alex Gontmakher is online but access to the full text requires paid membership.

With stuff this egregious, where are organizations such as the IEEE or ACM?

Well, the ACM has said publicly that it is opposed to the CBDTPA I am corresponding with the faculty advisor of the Indiana University Bloomington Student Chapter of the ACM as well as Tom Murphy (the infamous "font pirate") proposing the formation of a grassroots student movement to oppose legislation such as this. Information can be found at http://www.bloomington.in.us/~jswitte/ADFI.html . I would ask whoever AB3A is to respond to me concerning this.

This article does a terrible job of representing Ben Shneiderman's objections to Hal-like interfaces. The article focuses only the verbal memory issue.

But, Ben has been objecting to Hal-like interfaces for 20 years. He is a well-known computer science critic of artifical intelligence and intelligent agents. He specifically objects to making voice more practical by making the computer more intelligent. Just think of normal human conversation and the number of errors and corrections and hmms and ahs and redundancy elements. Verbal communication is rife with the potential for error, and add that to powerful, independent, software agents and you could have chaos. Ben doesn't want computers to be "clever secretaries" that take "initiative" on our behalf.

All the posts I've seen on this thread focus on the content of this one Washington Post article and are not written with knowledge of his extensive writings on the possibility and ethics of intelligent computer agents.

Here is one way of putting his fundamental objection. Would you rather have:

a) A surgeon working on your heart with his/her own hands?
or
b) A surgeon using a microphone to direct a robotic knife with only auditory feedback?

Even if the latter were programmed to "know" certain surgical tasks, isn't there a sense of a weak, indirection interaction with the device through voice? Wouldn't you feel better if the surgeon were more directly, visually connected to the system?

Ben's point has always been that direct, visual interfaction with objects (what he calls direct manipulation) will be safer and more efficient than a voice system, and that making the voice system smarter is not a solution to the problem.

Ben has debated this point in many forums. This spring he debated this at the AAAS (American Association for the Advancement of Science) conference with Jim Hendler, an AI prof at the University of Maryland. When I was a graduate student there years ago you could count on Ben to tweak the pure AI types as to the ethics and reliability of their work. A 1997 debate with Pattie Maes of MIT is easy to find online and is in PDF format. Try
CHI97 debate home
debate in PDF

Don't take this Washington Post article as anything but what it is, an extremely superficial summary of a complex position. There's lots more to read on this. In the long run, Ben's objections may be left in the dust, but for the moment he serves an important role by critically evaluating AI claims and predictions.

Hey! I honestly resent that remark. I have not one but two codes of ethics that I adhere to strictly. I know that the majority of programmers out there are only in it for the money, but I am not.

I hold myself as having more of a burden than almost any other profession, because let's face it: while a surgeon can maim one person at a time on the operating table, the nature of software makes it so that everything I do can affect the lives of hundreds, thousands, perhaps even millions.

In 1st year comp sci, we used to remember the constituents of the ACM CEPC this way:

I - Integrity
C - Competence
R - Responsibility
A - Pursuit of the Advancement of Human Welfare
P - Professionalism

These were all attributes or pursuits expected of ethical computer programmers.

Neither cover all important points and both have problems, but they are a good start. In particular neither are very clear when two requirements contradict. For example from the BCS Code of Conduct:
3. You shall have regard to the legitimate rights of third parties.
may contradict
4. You shall ensure that within your professional field/s you have knowledge and understanding of relevant legislation, regulations and standards, and that you comply with such requirements.
In some cases where DMCA or EUCD apply.

Despite these problems, the various documents are certainly worth a look:

• BCS Code of Conduct
• BCS Code of Practice
• ACM Code of Ethics and Professional Conduct