FLOSS Project Planets

Bits from Debian: Help empower the Debian Outreach Program for Women

Planet Debian - Thu, 2014-10-16 13:30

Debian is thrilled to participate in the 9th round of the GNOME FOSS Outreach Program. While OPW is similar to Google Summer of Code it has a winter session in addition to a summer session and is open to non-students.

Back at DebConf 14 several of us decided to volunteer because we want to increase diversity in Debian. Shortly thereafter the DPL announced Debian's participation in OPW 2014.

We have reached out to several corporate sponsors and are thrilled that so far Intel has agreed to fund an intern slot (in addition to the slot offered by the DPL)! While that makes two funded slots we have a third sponsor that has offered a challenge match: for each dollar donated by an individual to Debian the sponsor will donate another dollar for Debian OPW.

This is where we need your help! If we can raise $3,125 by October 22 that means we can mentor a third intern ($6,250). Please spread the word and donate today if you can at: http://debian.ch/opw2014/

If you'd like to participate as intern, the application deadline is the same (October 22nd). You can find out more on the Debian Wiki.

Categories: FLOSS Project Planets

PyCon: Posters due November 1, Early Bird tickets 50% sold

Planet Python - Thu, 2014-10-16 11:49
We're coming up on the end of our call for poster proposals! After the sugar rush of Halloween on October 31 (you all eat the candy right away, right?), poster proposals are due as long as it's November 1 somewhere in the world.

Since their start in Atlanta, the poster session has grown to be a key part of the conference, and we look forward to another successful run in 2015. If you ask me, the poster session is one of the best parts of PyCon. I presented a poster on two PSF initiatives (sprints and outreach) back in 2012 and had a great time sharing those committees, talking with people about what they were doing, how they could get involved, and a lot more. It was a great medium to make that presentation because it took attendees from being passive participants to active in the direction of what we talked about every few minutes.

For more information on the poster session, see our Call for Proposals!

Registration

Early bird ticket sales are just over 50% sold out! If you buy early you can save up to 25%, and we recommend you buy earlier than later because we're expecting our fourth consecutive sell out. Buy your tickets today at https://us.pycon.org/2015/registration/
Categories: FLOSS Project Planets

Calvin Spealman: Firefox Users on Linux Deserve Better Downloads

Planet Python - Thu, 2014-10-16 10:57
If you download Firefox on a linux machine today what you get from their servers is a pretty unfriendly tarball. What are you supposed to do with this? Maybe you know how to extract a tarball. Maybe you even know what of the many files inside it you're actually supposed to run and how to run it? Maybe.

But does everyone else? Do non-developer users have any clue what they're doing with this thing? They experience is awful.

I want to see that change and followed a ticket that tracks just that. What do you think?
Categories: FLOSS Project Planets

Dries Buytaert: Acquia a leader in Gartner Magic Quadrant for Web Content Management

Planet Drupal - Thu, 2014-10-16 08:23
Topic: DrupalAcquia

You might have read that Acquia was named a leader in the Gartner Magic Quadrant for Web Content Management.

It's easy to underestimate the importance of this recognition for both Acquia and Drupal to be in the leader quadrant. If you want to find a good coffee place, you use Yelp. If you want to find a nice hotel in New York, you use TripAdvisor. Similarly, if a CIO wants to spend $250,000 or more on enterprise software, they consult an analyst firm like Gartner. So think of Gartner as "Yelp for the enterprise".

Many companies create their technology shortlist based on the leader quadrant. That means that Drupal has not been considered as an option for hundreds of evaluations for large projects that have taken place in the past couple of years. Being named a leader alongside companies like Adobe, HP, IBM, Oracle, and Sitecore will encourage more organizations to evaluate Drupal. More organizations evaluating Drupal should benefit the Drupal ecosystem and the development of Drupal.

Categories: FLOSS Project Planets

Release party time!

Planet KDE - Thu, 2014-10-16 08:08

KDE Plasma 5.1Plasma 5.1 was released yesterday and it is looking real good. I have been running the 'next generation' Linux desktop on my laptop, courtesy of openSUSE packages made out of regular git snapshots. It was surprisingly stable so I have little worries about the stability of the final 5.1 release and I recommend to check it out ;-)

Of course, we should have a Plasma release party! We haven't had release parties in our place for a while (can't believe that the last one is over 2 years ago...), so it's time to do that again.

Check the release party page for details. The short of it:
  • October 18, 19:00-22:00 or so
  • EldenaerStrasse 28a, Berlin, Germany
  • Bring Your Own Devices Drinks (there's a Spätie (24h convenience store) downstairs). Food is welcome, too.
  • Don't forget to bring your good mood and friends

Further notes:
  • I might do some demoing of what is new in Plasma 5.1, depending on interest.
  • Anybody is welcome, as always, irrespective of color, sex, occupation, shape - heck, even species - you're all super welcome! That means you have to play nice with each other, do I have to say that?
  • If you're afraid of dogs, Popcorn will teach you that you don't have to be. But really, if she freaks you out, we can put her in another room, don't say home out of fear for the hairy monster!
  • Let me know if you're coming - so we have some idea of how crowded our apartment will be!

openSUSEFor the geekos among you: 13.2 is coming SOON and boy, is it chock-full of awesomeness! I'm talking to the Berlin LUG, we will probably do a release party. If possible we'll do it on November 8, so keep that date free for now!
Categories: FLOSS Project Planets

tanay.co.in: SA-CORE-2014-005 - All you need to know to protect your Drupal Site from the latest SQL Injection vulnerability

Planet Drupal - Thu, 2014-10-16 07:18

Last night, Drupal Release a security update to its core - v7.32

 

The release addresses the SQL Injection vulnerability described at https://www.drupal.org/SA-CORE-2014-005

 

 

How serious is it?

There are many proof of concepts scripts available all over the internet now. Both python and php variants. So, anyone who is knowledgeable enough to run a php/python script can now login to your Drupal 7 Site as admin, or execute any SQL on your Drupal Database!

[I am not linking them here for the obvious reasons, if you came here searching for those scripts, you are at the wrong place]

 

So, is my site vulnerable?

Most of the Drupal-special webhosts like Acquia, Pantheon, Platform.sh have apparently patched their platforms protecting your Drupal site even if your individual site has not been patched yet. So most of you are safe. You should be worried if you are hosting on one of those generic hosts to whom Drupal is just yet another script or if you are running the site on your own stack.

 

And if you have a CDN like cloudflare infront of your website, then you are safe as well (at least for a while). As of now, I am aware of only cloudflare that has announced that they have updated their Web App Firewall rules to mitigate this vulnerability. So if you are using Cloudflare CDN like I do for this blog site, make sure you turn on this option.

 

How do I fix my Site?

Don’t worry. Fortunately it is very simple. And it would not take more than 2 minutes to fix your site (if you do it via #3 below).

 

If the words like “git”, “patch”, “upgrade” scare you and if you like the words “FTP”, “Filezilla” more then skip directly to #3 below.

 

  • OPTION #1: The first option is to update your site to the latest version of Drupal - 7.32.

  • OPTION #2:But yeah, there is considerable effort involved behind upgrading your Drupal Site. Every upgrade usually would require significant regression testing and this could take a while.

    So, as an alternative, there is a very small patch out there for  you. Apply it and you are all set.
    Patch : https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch

    How do I apply this patch?
    Like any other patch -

  • OPTION #3: [THE SIMPLEST OF ALL] Alternatively, if you do not want to deal with patches or upgrades, or if you are are looking for a quick fix, here you go:

    • FTP to, or open your Drupal Root Directory

    • Navigate to  includes/database/ folder

    • There will be a file named database.inc . Take a backup of the file. We are going to modify the file. Store the backup somewhere safe just in case.

    • Open the file database.inc .

    • At around line 739, you will find a line of code that reads
      foreach ($data as $i => $value) {
      Replace this line with
      foreach (array_values($data) as $i => $value) {

    • Save the file and exit

    • Pat yourself on the back. You are all set now :-)

 


I have no enemies. Should I still fix my site?

Absolutely yes. With the many google dorks that could be used to find Drupal Sites, you could be the subject of random attack. - ie Some noob with the script picking up your site randomly to login as admin and defacing it or playing around with it, or stealing your userbase for spamming!

 

Who found this issue? Who reported it? When was it first reported? ……. Check out the FAQ on Drupal.org for answers - https://www.drupal.org/node/2357241

 
Categories: FLOSS Project Planets

Python Software Foundation: A new conference: Python Namibia!

Planet Python - Thu, 2014-10-16 07:10
The Python community has been fortunate to experience a lot of growth over the last few years, especially when it comes to user groups and conferences. A lot of these meetings have seen huge attendance, with PyCon having sold out the last three years, regional conferences seeing sharp growth, and some monthly meetups occasionally "selling out" (they're free, but attract more than the venue can hold). On top of those existing events growing, we're seeing more events pop up around the world.

We just got word that another new conference is starting up: Python Namibia, taking place February 2-5. This first time conference is taking place in Windhoek at the University of Namibia, with collaboration from Cardiff University, giving a group of students an opportunity to attend as part of their studies!

"Open-source software represents an opportunity for developing nations to become owners and producers of the software that they need; it's a key to their future prosperity," said organizer Daniele Procida. "There's an enormous benefit to software developers in being part of a supportive community."

The conference plans to start with two days of talks, a day of workshops and tutorials, and concluding with collaborative activities like sprints, as well as planning work for hosting a PyCon Namibia in 2016.

"We hope that this event will help programmers in Namibia feel that they belong to a welcoming international community that values their participation - and that it will help set a series of virtuous circles into motion," says Daniele.

Keep an eye on http://python-namibia.org/ and follow @PythonNamibia for more info!
Categories: FLOSS Project Planets

Visitors Voice: What is a good autocomplete?

Planet Drupal - Thu, 2014-10-16 06:45
Too often clients add autocomplete as an requirement without much thought. And as an result it is actually making the user experience worse. Instead of helping the users it confuses them. The first rule when designing autocomplete is: the suggestions must be relevant for many! Otherwise don’t make any suggestions at all, since it’s just […]
Categories: FLOSS Project Planets

Open Source Training: Drupal 7.32 is an Absolutely Necessary Update

Planet Drupal - Thu, 2014-10-16 05:03

We're accustomed to the Drupal security team releasing security fixes.

Fortunately, most of the fixes were relatively minor. They either impacted a small group of sites, or they were unlikely to lead to your site being hacked.

Let's take a brief look at the 4 previous Drupal security advisories in 2014:

Categories: FLOSS Project Planets

Make the World a Better Place! - KDE End of Year 2014 Fundraising

Planet KDE - Thu, 2014-10-16 03:35



At KDE sometimes we focus in the technical parts of Free Software. This is understandable since most of us are technical people doing a technical job.

But KDE also has a huge social impact, thanks to KDE there's schools that can teach touch typing , there's people out there that can do their accounting, there's business that can fill their taxes. KDE does provide quality software for all the world to use, making it a better place for all of us.

Donating to KDE is not for you, it is for the entire world.

As a way to say thank you, starting with € 30 KDE e.V. will send a KDE themed postcard to any given address. You will get an extra card for every additional € 10 donation.

More at https://www.kde.org/fundraisers/yearend2014/

Categories: FLOSS Project Planets

PreviousNext: Constructive Conflict Resolution in the Drupal Community

Planet Drupal - Thu, 2014-10-16 00:06

How can the Drupal community recognise and handle conflict more constructively? This core conversation session from DrupalCon Amsterdam aimed to start a discussion about creating an army of empowered bystanders ready, willing and able to use conflict as a positive force in the community.

Categories: FLOSS Project Planets

PreviousNext: Constructive Conflict Resolution in the Drupal Community

Planet Drupal - Thu, 2014-10-16 00:06

How can the Drupal community recognise and handle conflict more constructively? This core conversation session from DrupalCon Amsterdam aimed to start a discussion about creating an army of empowered bystanders ready, willing and able to use conflict as a positive force in the community.

Categories: FLOSS Project Planets

Midwestern Mac, LLC: Fixing Drupal Fast - Using Ansible to deploy a security update on many sites

Planet Drupal - Thu, 2014-10-16 00:01

Earlier today, the Drupal Security Team announced SA-CORE-2014-005 - Drupal core - SQL injection, a 'Highly Critical' bug in Drupal 7 core that could result in SQL injection, leading to a whole host of other problems.

While not a regular occurrence, this kind of vulnerability is disclosed from time to time—if not in Drupal core, in some popular contributed module, or in some package you have running on your Internet-connected servers. What's the best way to update your entire infrastructure (all your sites and servers) against a vulnerability like this, and fast? High profile sites could be quickly targeted by criminals, and need to be able to deploy a fix ASAP... and though lower-profile sites may not be immediately targeted, you can bet there will eventually be a malicious bot scanning for vulnerable sites, so these sites need to still apply the fix in a timely manner.

Categories: FLOSS Project Planets

Calvin Spealman: Dead to Me! Trapdoor, Prototyping web-based desktop applications

Planet Python - Wed, 2014-10-15 23:53
This is the inaugural post in my Dead to Me! series which I announced.

I’m not gonna lie. I’m pretty proud of this one. To say Trapdoor was ahead of the times might be a stretch, but really only a small stretch.

My project README explains

Trapdoor is a web-based desktop framework. Confused yet? The idea is to leverage how much energy is put into the web today and make developing a desktop application fun again. Again? For the first time?

Trapdoor was an exploration of how to utilize web development skillsets to build desktop tools. I wanted to experiment with how this idea would play out and if it really made any sense. I was never planning Trapdoor to become are solution. I just wanted to play with the idea, but I do think I played with the idea pretty early on and that it was an extremely successful experiment.

At the time I was still a KDE user and had been learning a little bit of Qt via the Python bindings PyQt4. I knew that Qt had a WebKit widget and quickly found that PyQt4 exposed this pretty easily.




This was a simple demo I built with Trapdoor. We have a web-app built, for this simple example, all in Javascript dumping a few simple controls to the DOM. The JS is responsible for window creation and gets access to the DOM in the new window, where it can construct an interface in HTML and use jQuery to wire it up.

What I was most proud of is that, recognizing this would only be useful if the desktop applications being built could do anything a normal desktop app could do, I made it really easy to extend the Javascript APIs with new things.

The Calculator class defined in the above calculator.py file above and registered in the manifest is able to expose methods to the Javascript API it injects into the application. Otherwise, it is just regular everyday Python and can do anything and can use any Python libraries.

I only worked on Trapdoor for three days. Vaguely I recall wondering if I could write an extension that used PyOpenGL to render 3D graphics in my web-based desktop application, a good year before the WebGL spec landed and three and a half years before work would begin on Node Webkit. Trapdoor won’t be worked on by me and shouldn’t be picked up by anyone else, probably. It will continue to sit in my Github for a while, but it stay forever among my favorite personal projects.
Check it out, if you’re curious.
Categories: FLOSS Project Planets

Calvin Spealman: Dead to Me!

Planet Python - Wed, 2014-10-15 23:48
Dead to Me! is a new thing I’m doing. This is not a new blog, but it is a specific series of posts within this blog. Dead to Me! is about those projects which I am only looking back on, but will not work on again. These aren’t all failed experiments, but some of them are. In each post I’ll talk about a project I’ve abandoned, sunsetted, or moved on from. Some of them will be recent and others will be things I worked on years ago. Some of them might be related to work, but most will be personal.

I’m also doing something different with this. I don’t know how well this part will work out, but I’ve already gotten some interest in it so we’ll see:

I am soliciting for guest posts to Dead to Me! and welcome anyone who would like to ask to be a part of this. If you have a project you’re no longer working on and would like to write a postmortem for, please drop me a line or a draft.

If you’d like your post to appear here, go ahead and post it on your own blog or anywhere else, as well. Perhaps we can cross-link them.
I think this will be fun. Will you join me?

You can read the first post of the Dead to Me! series right now, about Trapdoor, a prototype platform for web-based desktop application development.
Categories: FLOSS Project Planets

Bryan Pendleton: Stuff I'm reading, mid-October edition

Planet Apache - Wed, 2014-10-15 23:43

There was wind last night, but no rain.

Rain to the north, they say.

But not here.

  • Harvest and Yield: Not A Natural Cure for Tradeoff ConfusionYield is the availability metric that most practitioners end up working with, and it's worth noting that its different from CAP's A. The authors don't define it formally, but treat it as a long-term probability of response rather than the probability of a response conditioned on there being a failure. That's a good common-sense definition, and one that fits well with the way that most practitioners think about availability.
  • Apple's "Warrant-Proof" EncryptionCode is often buggy and insecure; the more code a system has, the less likely it is to be secure. This is an argument that has been made many times in this very context, ranging from debates over the Clipper Chip and key escrow in the 1990s to a recent paper by myself, Matt, Susan Landau, and Sandy Clark. The number of failures in such systems has been considerable; while it is certainly possible to write more secure code, there's no reason to think that Apple has done so here. (There's a brand-new report of a serious security hole in iOS.) Writing secure code is hard. The existence of the back door, then, enables certain crimes: computer crimes. Add to that the fact that the new version of iOS will include payment mechanisms and we see the risk of financial crimes as well.
  • Keyless SSL: The Nitty Gritty Technical DetailsExtending the TLS handshake in this way required changes to the NGINX server and OpenSSL to make the private key operation both remote and non-blocking (so NGINX can continue with other requests while waiting for the key server). Both the NGINX/OpenSSL changes, the protocol between the CloudFlare’s server, and the key server were audited by iSEC Partners and Matasano Security. They found the security of Keyless SSL equivalent to on-premise SSL. Keyless SSL has also been studied by academic researchers from both provable security and performance angles.
  • Intel® SGX for Dummies (Intel® SGX Design Objectives)At its root, Intel® SGX is a set of new CPU instructions that can be used by applications to set aside private regions of code and data. But looking at the technology upward from the instructions is analogous to trying to describe an animal by examining its DNA chain. In this short post I will try to uplevel things a bit by outlining the objectives that guided the design of Intel® SGX and provide some more detail on two of the objectives.
  • Ads Don't Work That WayThe key differentiating factor between the two mechanisms (inception and imprinting) is how conspicuous the ad needs to be. Insofar as an ad works by inception, its effect takes place entirely between the ad and an individual viewer; the ad doesn't need to be conspicuous at all. On the other hand, for an ad to work by cultural imprinting, it needs to be placed in a conspicuous location, where viewers will see it and know that others are seeing it too.
  • The ultimate weapon against GamerGate time-wasters: a 1960s chat bot that wastes their timeAlan Turing proposed that an artificial intelligence qualified as a capable of thought if a human subject, in conversation with it and another human, cannot tell them apart; the strange thing about the Eliza Twitter bot is it doesn't come across as any more like a machine than those who keep repeating their points over and over and over, ad nauseum. It's difficult to decide who's failed the Turing test here.
  • Gabriel Knight’s Creator Releases Incredible 20th Anniversary RemakeStaring at the remake version brings all those old memories of DOS mouse drivers and command prompts flooding back. Gazing at protagonist Gabriel Knight’s dazzling, polychromatic bookstore (your base of operations in New Orleans as the game begins) is like seeing the mental interpolation your brain made of the original pixelated wash beautifully, if weirdly, reified.
  • Bridge Troll I know this sounds a bit crazy, but trust me, there’s a troll up there! He or she, it’s tough to tell the gender of trolls, is approximately two feet tall, made of steel, and perched atop the southern end of the transverse concrete beam where the eastern cable makes contact with the road deck. The troll cannot be seen by car or from the bike path next to the bridge—you need to be underneath the bridge, on a boat to actually see the bridge troll.
  • Don’t Mourn the Passing of the New York Times Chess ColumnIf those who know enough about the game to understand the diagrams in a newspaper chess column can access thousands of times more information, free and instantly, than a weekly column could possibly provide, then why run one at all? The answer is that most weekly newspaper chess columns don’t need to exist and won’t in the near future. The one exception: when there’s an excellent writer and chess professional at the helm, someone like Robert Byrne.
  • Serbia vs. Albania in Belgrade brings their troubled history to the fore But even if football takes the headlines, there is still the sense that Tuesday night might be an opportunity missed. On October 22, Albanian Prime Minister Edi Rama will visit Belgrade to discuss bilateral relations with his Serbian counterpart, Aleksandar Vukic. No Albanian leader has visited Belgrade since Enver Hoxha in 1946.

    It is significant, and maybe it brings a glimmer of hope that a repeat of Tuesday's fixture might one day be all about the game instead. Having a harmonious football match to oil the conversation would have done little harm, but the anticipation of that noticeable absense inside Partizan Stadium stands as a reminder that sport does not always have the power to untangle wider complexities.

  • In TransitionWe picked 10 of the most progressive skaters to choose one location each and film a full part.
  • Things I Won't Work With: Dioxygen DifluorideThe paper goes on to react FOOF with everything else you wouldn't react it with: ammonia ("vigorous", this at 100K), water ice (explosion, natch), chlorine ("violent explosion", so he added it more slowly the second time), red phosphorus (not good), bromine fluoride, chlorine trifluoride (say what?), perchloryl fluoride (!), tetrafluorohydrazine (how on Earth. . .), and on, and on. If the paper weren't laid out in complete grammatical sentences and published in JACS, you'd swear it was the work of a violent lunatic. I ran out of vulgar expletives after the second page. A. G. Streng, folks, absolutely takes the corrosive exploding cake, and I have to tip my asbestos-lined titanium hat to him.
Categories: FLOSS Project Planets

Calvin Spealman: On Atheism Plus

Planet Python - Wed, 2014-10-15 23:09
This was originally published on That Liberal Extremist, a blog on social and political issues I began with my wife Heather.

"Atheism Plus" has been making rounds for a while now.

The basic premise seems to be Atheism, plus a lot of social justice movement elements. And, completely, I support that. And I'm glad for the wide support from others I see from that. We should support women in the Atheist community, and gays and bisexuals and the transgendered among us. And those outside of us, who are still marginalized even by religions they're a part of. We should support people of color, and the poor, and immigrants and single mothers more. Intersectionality is the word.
I came across this idea first from Greta Christina's post
But, I don't think we need a label for this. That doesn't mean there isn't a reason for it, and maybe I should phrase it "I don't think we should need it.", so let me explain.
...the rest of the post continues at That Liberal Extremist. Please subscribe if that's the kind of writing from me you're interested in.
Categories: FLOSS Project Planets

Python Diary: Building a CPU simulator in Python

Planet Python - Wed, 2014-10-15 21:44
You can find the entire source listing from this article, plus more interesting code on my Python Experiments BitBucket page. Plus, the source code there will evolve and grow.

Early this morning in my Planet Python feed, I read this really interesting article called Developing Upwards: CARDIAC: The Cardboard Computer, which is about this cardboard computer called the Cardiac. As some of my followers and readers might know, I have another project that I have been working on and evolving for the past months called simple-cpu, which I have released the source code for. I really should give that project a proper license so that others might feel interested in using it in their own projects... Anyways, hopefully I'll have that done by the time this publishes.

After reading that article and the page it links to, I felt a bit inspired and decided to write my own simulator for it since I already have experience in writing bytecode engines. I plan on following this article up with another on how to write a Assembler for it, then shortly after how to write a compiler. So basically, throughout these articles, you will learn how to create a build toolchain for the Cardiac in Python. The simple-cpu I wrote already has a fully working Assembler, and in the game I am putting it in, already has the first steps of a working compiler. I choose to also use Cardiac as a demonstration machine due to it's pure simplicity. There are no really complex mnemonics here, each opcode only accepts a single parameter, so it's perfect as a learning tool. Furthermore, all data parameters are known to be the same, there is no need to detect if the program wants a register, a literal, or a memory address. In fact, there is really only one register, the accumulator. So lets get started. We will be making this class-based, so that the scope is contained and so that you can easily sub-class it to say add new opcodes if you want to feel adventurous. First, we will focus on the Initialization routines. This CPU is very simple, so we only need to initialize the following: CPU registers, opcodes, memory space, card reader/input, and the printer/tty/output.

class Cardiac(object): """ This class is the cardiac "CPU". """ def __init__(self): self.init_cpu() self.reset() self.init_mem() self.init_reader() self.init_output() def reset(self): """ This method resets the CPU's registers to their defaults. """ self.pc = 0 #: Program Counter self.ir = 0 #: Instruction Register self.acc = 0 #: Accumulator self.running = False #: Are we running? def init_cpu(self): """ This fancy method will automatically build a list of our opcodes into a hash. This enables us to build a typical case/select system in Python and also keeps things more DRY. We could have also used the getattr during the process() method before, and wrapped it around a try/except block, but that looks a bit messy. This keeps things clean and simple with a nice one-to-one call-map. """ self.__opcodes = {} classes = [self.__class__] #: This holds all the classes and base classes. while classes: cls = classes.pop() # Pop the classes stack and being if cls.__bases__: # Does this class have any base classes? classes = classes + list(cls.__bases__) for name in dir(cls): # Lets iterate through the names. if name[:7] == 'opcode_': # We only want opcodes here. try: opcode = int(name[7:]) except ValueError: raise NameError('Opcodes must be numeric, invalid opcode: %s' % name[7:]) self.__opcodes.update({opcode:getattr(self, 'opcode_%s' % opcode)}) def init_mem(self): """ This method resets the Cardiac's memory space to all blank strings, as per Cardiac specs. """ self.mem = ['' for i in range(0,100)] self.mem[0] = '001' #: The Cardiac bootstrap operation. def init_reader(self): """ This method initializes the input reader. """ self.reader = [] #: This variable can be accessed after initializing the class to provide input data. def init_output(self): """ This method initializes the output deck/paper/printer/teletype/etc... """ self.output = []

Hopefully I left enough comments in the code above for you to understand exactly what's going on here. You might notice here a key difference from my simple-cpu project, is the method which opcodes are handled. I actually plan on incorporating this new way of detecting opcodes into that project in the near future. This method makes it easier for other developers of the library to extend it for their own requirements. As mentioned before, that project has been evolving as I started to understand more about how things should be done. In fact, taking on a CPU simulator project is a really incredible learning experience all on it's own. If you are truly a computer scientist, you should understand the under workings of a CPU, and how each opcode is processed at it's lowest level. Plus, developing and seeing a custom built CPU simulator made by your own imagination is a very gratifying experience. It's almost like giving birth, as this machine was entirely built by your mind alone, and seeing it work, is something magical.

In the next part of this class, we will focus on the utility functions that we may need to call and use multiple times, these methods can also be overridden in subclasses to alter how the CPU actually functions:

def read_deck(self, fname): """ This method will read a list of instructions into the reader. """ self.reader = [s.rstrip('\n') for s in open(fname, 'r').readlines()] self.reader.reverse() def fetch(self): """ This method retrieves an instruction from memory address pointed to by the program pointer. Then we increment the program pointer. """ self.ir = int(self.mem[self.pc]) self.pc +=1 def get_memint(self, data): """ Since our memory storage is *string* based, like the real Cardiac, we need a reusable function to grab a integer from memory. This method could be overridden if say a new memory type was implemented, say an mmap one. """ return int(self.mem[data]) def pad(self, data, length=3): """ This function pads either an integer or a number in string format with zeros. This is needed to replicate the exact behavior of the Cardiac. """ orig = int(data) padding = '0'*length data = '%s%s' % (padding, abs(data)) if orig < 0: return '-'+data[-length:] return data[-length:]

These are the various utility functions, all of which might be overridden in a subclass. Later in this article, I will also provide an alternate source output which displays how this simulator can be built using Python Mixin classes, to make things even more pluggable. Finally, we find ourselves at the final part of code to get this simulator running, the actual processing methods:

def process(self): """ Process a single opcode from the current program counter. This is normally called from the running loop, but can also be called manually to provide a "step-by-step" debugging interface, or to slow down execution using time.sleep(). This is the method that will also need to used if you build a TK/GTK/Qt/curses frontend to control execution in another thread of operation. """ self.fetch() opcode, data = int(math.floor(self.ir / 100)), self.ir % 100 self.__opcodes[opcode](data) def opcode_0(self, data): """ INPUT Operation """ self.mem[data] = self.reader.pop() def opcode_1(self, data): """ Clear and Add Operation """ self.acc = self.get_memint(data) def opcode_2(self, data): """ Add Operation """ self.acc += self.get_memint(data) def opcode_3(self, data): """ Test Accumulator contents Operation """ if self.acc < 0: self.pc = data def opcode_4(self, data): """ Shift operation """ x,y = int(math.floor(data / 10)), int(data % 10) for i in range(0,x): self.acc = (self.acc * 10) % 10000 for i in range(0,y): self.acc = int(math.floor(self.acc / 10)) def opcode_5(self, data): """ Output operation """ self.output.append(self.mem[data]) def opcode_6(self, data): """ Store operation """ self.mem[data] = self.pad(self.acc) def opcode_7(self, data): """ Subtract Operation """ self.acc -= self.get_memint(data) def opcode_8(self, data): """ Unconditional Jump operation """ self.pc = data def opcode_9(self, data): """ Halt and Reset operation """ self.reset() def run(self, pc=None): """ Runs code in memory until halt/reset opcode. """ if pc: self.pc = pc self.running = True while self.running: self.process() print "Output:\n%s" % '\n'.join(self.output) self.init_output() if __name__ == '__main__': c = Cardiac() c.read_deck('deck1.txt') try: c.run() except: print "IR: %s\nPC: %s\nOutput: %s\n" % (c.ir, c.pc, '\n'.join(c.output)) raise

As mentioned above, I will now refactor the code into Mixin classes and provide a full source output of that:

class Memory(object): """ This class controls the virtual memory space of the simulator. """ def init_mem(self): """ This method resets the Cardiac's memory space to all blank strings, as per Cardiac specs. """ self.mem = ['' for i in range(0,100)] self.mem[0] = '001' #: The Cardiac bootstrap operation. def get_memint(self, data): """ Since our memory storage is *string* based, like the real Cardiac, we need a reusable function to grab a integer from memory. This method could be overridden if say a new memory type was implemented, say an mmap one. """ return int(self.mem[data]) def pad(self, data, length=3): """ This function pads either an integer or a number in string format with zeros. This is needed to replicate the exact behavior of the Cardiac. """ orig = int(data) padding = '0'*length data = '%s%s' % (padding, abs(data)) if orig < 0: return '-'+data[-length:] return data[-length:] class IO(object): """ This class controls the virtual I/O of the simulator. To enable alternate methods of input and output, swap this. """ def init_reader(self): """ This method initializes the input reader. """ self.reader = [] #: This variable can be accessed after initializing the class to provide input data. def init_output(self): """ This method initializes the output deck/paper/printer/teletype/etc... """ self.output = [] def read_deck(self, fname): """ This method will read a list of instructions into the reader. """ self.reader = [s.rstrip('\n') for s in open(fname, 'r').readlines()] self.reader.reverse() def format_output(self): """ This method is to format the output of this virtual IO device. """ return '\n'.join(self.output) def get_input(self): """ This method is used to get input from this IO device, this could say be replaced with raw_input() to manually enter in data. """ try: return self.reader.pop() except IndexError: # Fall back to raw_input() in the case of EOF on the reader. return raw_input('INP: ')[:3] def stdout(self, data): self.output.append(data) class CPU(object): """ This class is the cardiac "CPU". """ def __init__(self): self.init_cpu() self.reset() try: self.init_mem() except AttributeError: raise NotImplementedError('You need to Mixin a memory-enabled class.') try: self.init_reader() self.init_output() except AttributeError: raise NotImplementedError('You need to Mixin a IO-enabled class.') def reset(self): """ This method resets the CPU's registers to their defaults. """ self.pc = 0 #: Program Counter self.ir = 0 #: Instruction Register self.acc = 0 #: Accumulator self.running = False #: Are we running? def init_cpu(self): """ This fancy method will automatically build a list of our opcodes into a hash. This enables us to build a typical case/select system in Python and also keeps things more DRY. We could have also used the getattr during the process() method before, and wrapped it around a try/except block, but that looks a bit messy. This keeps things clean and simple with a nice one-to-one call-map. """ self.__opcodes = {} classes = [self.__class__] #: This holds all the classes and base classes. while classes: cls = classes.pop() # Pop the classes stack and being if cls.__bases__: # Does this class have any base classes? classes = classes + list(cls.__bases__) for name in dir(cls): # Lets iterate through the names. if name[:7] == 'opcode_': # We only want opcodes here. try: opcode = int(name[7:]) except ValueError: raise NameError('Opcodes must be numeric, invalid opcode: %s' % name[7:]) self.__opcodes.update({opcode:getattr(self, 'opcode_%s' % opcode)}) def fetch(self): """ This method retrieves an instruction from memory address pointed to by the program pointer. Then we increment the program pointer. """ self.ir = self.get_memint(self.pc) self.pc +=1 def process(self): """ Process a single opcode from the current program counter. This is normally called from the running loop, but can also be called manually to provide a "step-by-step" debugging interface, or to slow down execution using time.sleep(). This is the method that will also need to used if you build a TK/GTK/Qt/curses frontend to control execution in another thread of operation. """ self.fetch() opcode, data = int(math.floor(self.ir / 100)), self.ir % 100 self.__opcodes[opcode](data) def opcode_0(self, data): """ INPUT Operation """ self.mem[data] = self.get_input() def opcode_1(self, data): """ Clear and Add Operation """ self.acc = self.get_memint(data) def opcode_2(self, data): """ Add Operation """ self.acc += self.get_memint(data) def opcode_3(self, data): """ Test Accumulator contents Operation """ if self.acc < 0: self.pc = data def opcode_4(self, data): """ Shift operation """ x,y = int(math.floor(data / 10)), int(data % 10) for i in range(0,x): self.acc = (self.acc * 10) % 10000 for i in range(0,y): self.acc = int(math.floor(self.acc / 10)) def opcode_5(self, data): """ Output operation """ self.stdout(self.mem[data]) def opcode_6(self, data): """ Store operation """ self.mem[data] = self.pad(self.acc) def opcode_7(self, data): """ Subtract Operation """ self.acc -= self.get_memint(data) def opcode_8(self, data): """ Unconditional Jump operation """ self.pc = data def opcode_9(self, data): """ Halt and Reset operation """ self.reset() def run(self, pc=None): """ Runs code in memory until halt/reset opcode. """ if pc: self.pc = pc self.running = True while self.running: self.process() print "Output:\n%s" % self.format_output() self.init_output() class Cardiac(CPU, Memory, IO): pass if __name__ == '__main__': c = Cardiac() c.read_deck('deck1.txt') try: c.run() except: print "IR: %s\nPC: %s\nOutput: %s\n" % (c.ir, c.pc, c.format_output()) raise

You can find the code for deck1.txt from the Developing Upwards: CARDIAC: The Cardboard Computer article, I used the counting to 10 example.

Hopefully this article was inspiring to you and gives you a brief understanding on how to built class-bases modular and pluggable code in Python, and also gave you a nice introduction to developing a CPU simulator. In the next article which I hope to publish soon, will guide you through making a basic assembler for this CPU, so that you can easily and effortlessly create decks to play around with in the simulator.

Categories: FLOSS Project Planets

Armin Ronacher: On Error Handling in Rust

Planet Python - Wed, 2014-10-15 20:00

Rust is improving quite a lot lately and it makes it very exciting to play with the language and see how good API design could look like. There are areas in it however that are a bit frustrating still. For me one area is error handling. But some improvements might be coming up which I find quite exciting because it changes things around a bit from what most people are used to.

I actually wanted to write about about the API design in my little redis library but I expect the changes in the error handling to change the dynamics around a lot. Because of that I want to write a bit about the error handling in Rust currently and where it could be going.

Rust's Concept of Failure

Rust at present has two ways to indicate failure: results and hard task failures. In practical terms only the former is actually what you should be concerned with. Task failures are a last resort that you can fall back to if there is nobody who can pick up on your problem or if the problem is just of a nature that does not permit any error handling.

At present a result is as good as it gets. A type Result<T, E> has two possible states in which it can be: OK(T) or Err(E). So it either succeeded with an object of value T or it failed with an object of value E.

I think this concept in generally is quite obvious to developers, even if they have not used Rust. Because failures are quite common there is also a macro provided in Rust called try! which implements an early return that propagates the error part upwards:

fn load_document() -> Result<Document, DatabaseError> { let db = try!(open_database()); try!(db.load("document_1")) }

With the try! macro expanded it looks a bit like this:

fn load_document() -> Result<Document, DatabaseError> { let db = match open_database() { Ok(x) => x, Err(err) => { return Err(err); } }; match db.load("document_1") { Ok(x) => x, Err(err) => { return Err(err); } } }

As you can see, the try! macro makes things quite straightforward. There is however quite a big problem with it, and that is that all the errors from the function have to be the same. In many cases that is just wrong. A good example is my redis-rs library. Since all operations are happening over sockets you can either get an IOError or you might be presented with a redis specific error.

Errors Across Abstraction Boundaries

The problem of errors that want to cross an abstraction boundary are a long standing issue in many programming languages. There have been quite a few extreme approaches to this problem.

The most extreme example is probably the concept of unchecked exceptions. In Python for instance anything can fail with any error. This fit's Python's design quite well because Python is a highly dynamic language and until you actually execute the thing you don't really know what's going to happen. However the same concept also exists in C# and other more static languages where it feels much more alien.

Java has checked exceptions which have a terrible reputation (deservedly). With checked exceptions you have the guarantee that (with the exception of runtime exceptions which also exist) an API will not raise you an exception you cannot deal with. However it suffers from the same general problem as you currently have in Rust where you need to figure out what exactly you should do when your contract to the outside world is that you only raise exception X but the function you are calling into raises exception Z. In Java this is especially annoying because the error handling is very involved.

In some other languages like C the errors typically are an in-band signal that indicates that something went wrong and an some state elsewhere that you can query to figure out what happened. This is by far the worst because it requires that something holds state for you but it's reasonably flexible.

The Python interpreter for instance has a thread local variable that contains the "interpreter state" which holds a reference to the last actual error that happened. Individual calls return NULL pointers or other indicator values. When you fail in a function you return NULL after creating an error object and storing in the interpreter state. If you call into another function and you can see that a failure indicator (NULL pointer) comes back you just propagate the failure upwards. Once something that can handle the error sees a NULL it can go back to the interpreter state to figure out what exactly happened.

What Rust has in Mind

One of the proposals for Rust currently introduce a new concept which combines various different approaches by changing how errors would propagate. It sticks with the general idea that your functions return your errors but it introduces the concept of error interoperability.

Think of it like this: the contract your library has with the outside world is that your library exposes a certain behavior and some behavior is an implementation detail. While it's fairly obvious that your database library will eventually do IO to talk to the database, it does not mean that it will always do. This has always been a problem with checked exceptions in Java because some of the interfaces do not make sense in all circumstances. If for instance my redis library would ever start talking to an in-memory simulation of Redis it will probably stop producing IO errors internally.

The idea of the proposal is twofold. The first one is that errors generally follow a common pattern. An error is whatever the user wants it to be, but it needs to implement the Error trait and implement some general methods to extract some information out of the error (Like a description that gives an error message and optionally some more detail information). In addition the neat aspect is that an error can have a cause which points to another error.

So in case of my redis library for instance if the library would have to report an IO error it would report a redis error with a message like "Encountered an IO error while talking to the server" and links back to the actual IO error.

To wrap an error in another error the FromError trait exists that can facilitate this. So my redis library would implement a conversion of IOError to a RedisError that also stores the IO error as cause.

The elegance becomes obvious once you see the actual usage code in action:

impl FromError<IOError> for RedisError { fn from_err(err: IOError) -> RedisError { RedisError { descr: "Encountered an IO error", cause: Some(err), } } } fn read_value(host, port) -> Result<Parser, RedisError> { let sock = try!(TcpStream::connect(host, port)); let mut parser = Parser::new(&mut sock as &mut Reader); try!(parser.parse_value()) }

The TcpStream::connection method fails with an IOError. Because our own function fails with RedisError, the try! macro will automatically invoke the FromError::from_err method to create a new redis error that wraps the cause one. Now we just need to make sure that RedisError implements the Error trait to provide the useful bits for introspection.

From try! To Navigation

But this is not where Rust wants to stop. There is another RFC which proposes an operator to replace the try! macro with an operator and it's actually really neat.

In a nutshell try!(x) would become x?. The consequences are quite cool because you can then arbitrarily nest failure conditions:

fn load_document() -> Result<Document, DatabaseError> { open_database()?.load("document_1") }

This is quite a dramatic improvement over the initial version. There are even more things proposed that would go quite far in emulating exceptions without exceptions. For more information read the RFC.

And in Python?

I think the interesting bit about the FromError trait is that the general concept is very good in other languages too. In Python for instance it would be very welcome if libraries would start being a bit more hygienic with the exceptions they can report. For instance with the requests library I generally have to catch down a whole bunch of exceptions that are not officially part of the contract (socket exceptions, SSL errors etc.).

Especially in Python 3 where exceptions generally get chained if rethrown correctly there really is no reason for not catching down and rethrowing internal exceptions through one exception type of the library. Having to only deal with a RequestFailed exception is much more convenient and future proof.

Categories: FLOSS Project Planets

GNUtls: POODLE attack

GNU Planet! - Wed, 2014-10-15 20:00

Posted a security advisory on the POODLE attack.

Categories: FLOSS Project Planets
Syndicate content