Implementing the hardening
When packaging in Debian, is very common to see the lintian messages 'hardening-no-relro' and 'hardening-no-fortify-functions' in some softwares written in C or C++. To solve these issues, we can use the 'blhc' tool (apt-get install blhc).
Please, get the revision 1.11-9 of the icmpinfo package. You can get this revision from
http://snapshot.debian.org or from
http://eriberto.pro.br/debian/icmpinfo. As a shortcut, you can use the following command:
$ dget -u http://eriberto.pro.br/debian/icmpinfo/icmpinfo_1.11-9.dsc
The icmpinfo 1.11-9 is almost clean for lintian (in 2015-09-07, Standards-Version 3.9.6). The only problem is:
W: icmpinfo: hardening-no-relro usr/sbin/icmpinfo
To track the problem I will use
blhc over the
.build file:
$ blhc icmpinfo_1.11-9_amd64.build
LDFLAGS missing (-Wl,-z,relro): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -o icmpinfo recvping.o print.o err.o icmpinfo.o pid.o
Note that the problem is some missing options (-Wl,-z,relro) for LDFLAGS when building icmpinfo (for newbies, in GCC, -o is used to indicate the name to be used for the final binary after the compilation). If you are using the DebHelper compat 9 (debian/compat=9) and the DebHelper 9 (debhelper >= 9 in Build-Depends field in d/control), some variables as CFLAGS, LDFLAGS, CPPFLAGS and CXXFLAGS will be automatically passed during calls to dh_auto_* programs (yes, you should use the new and reduced d/rules format - see as example the debian/rules of the icmpinfo 1.11-9; if you still have doubts, $ man dh).
Now, we need discover the reason why the LDFLAGS is being changed between its generation by the Debian build system and its utilization by the upstream's source code. So, we need to check the upstream Makefile.
There is in Makefile (after a 'quilt push -a', to apply all current patches):
LDFLAGS= $(CFLAGS)
OBJECTS= recvping.o print.o err.o icmpinfo.o pid.o
TARGET = icmpinfo
$(TARGET): $(OBJECTS)
$(CC) $(LDFLAGS) -o $@ $(OBJECTS) $(LDLIBS)
Hummm... The LDFLAGS content generated by Debian is being dropped by Makefile because it is saying that "LDFLAGS = CFLAGS content". This line is a problem because the upstream Makefile needs to take and use the CFLAGS and LDFLAGS independently. To fix the issue, you can use this patch:
--- icmpinfo-1.11.orig/Makefile
+++ icmpinfo-1.11/Makefile
@@ -20,13 +20,13 @@ VERS = 1.11
RM = rm -f
-LDFLAGS= $(CFLAGS)
+#LDFLAGS= $(CFLAGS)
OBJECTS= recvping.o print.o err.o icmpinfo.o pid.o
TARGET = icmpinfo
$(TARGET): $(OBJECTS)
- $(CC) $(LDFLAGS) -o $@ $(OBJECTS) $(LDLIBS)
+ $(CC) $(LDFLAGS) $(CFLAGS) -o $@ $(OBJECTS) $(LDLIBS)
tgz: clean
rm -f CHECKSUMS.asc
After a 'debuild' is a fact the problem is solved and the lintian is happy. See the blhc results:
$ blhc ../icmpinfo_1.11-9_amd64.build
$
Now, we can improve the hardening. To see the current status, we can use the 'blhc --all' command. See here:
blhc --all ../icmpinfo_1.11-9_amd64.build
CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -c -o recvping.o recvping.c
CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -c -o print.o print.c
CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -c -o err.o err.c
CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -c -o icmpinfo.o icmpinfo.c
CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -c -o pid.o pid.c
LDFLAGS missing (-fPIE -pie -Wl,-z,now): cc -Wl,-z,relro -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -o icmpinfo recvping.o print.o err.o icmpinfo.o pid.o
Well, we know that CFLAGS and LDFLAGS are present. Now, we can force the DebHelper to pass some extra options to make hardening better. Generally, is only needed to add the following line to debian/rules:
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
See the results (after a new debuild command):
$ blhc --all ../icmpinfo_1.11-9_amd64.build
$
More examples
Let me to show other example. I will use the mac-robber 1.02-3 (however, I disabled the Makefile.patch in debian/patches/series). After a debuild, the following lintian messages are presented:
W: mac-robber: hardening-no-relro usr/bin/mac-robber
I: mac-robber: hardening-no-fortify-functions usr/bin/mac-robber
Using blhc:
$ blhc ../mac-robber_1.02-3_amd64.build
CFLAGS missing (-g -O2 -fstack-protector-strong -Wformat -Werror=format-security): gcc -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c
CPPFLAGS missing (-D_FORTIFY_SOURCE=2): gcc -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c
LDFLAGS missing (-Wl,-z,relro): gcc -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c
We need to verify what is the problem in Makefile with CFLAGS, CPPFLAGS and LDFLAGS when generating the binary 'mac-robber' (just recalling, -o mac-robber in GCC command). See:
linux_notstatic:
$(CC) -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c
There are no references to CFLAGS, CPPFLAGS and LDFLAGS. To solve the problem, we need patch the Makefile to make this:
linux_notstatic:
$(CC) $(CFLAGS) $(LDFLAGS) $(CPPFLAGS) -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c
As last example, is possible that the Makefile is overriding the content sent by DebHelper when building. See this line from a hypothetical Makefile:
CFLAGS = -g -Wall
As you can see, the Makefile is redefining CFLAGS; consequently, it is discarding any previous content sent by DebHelper. To solve this issue, we can use the following patch:
-CFLAGS = -g -Wall
+CFLAGS += -g -Wall
So, the content received from DebHelper will be added to '-g -Wall'.
Default parameters
As curiosity, to see the basic parameters created by DebHelper as hardening, use the command:
$ dpkg-buildflags
To see the all parameters, use the command:
$ DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags
More information
More information about the hardening can be viewed at two places:
https://wiki.debian.org/Hardening
https://wiki.debian.org/HardeningWalkthrough
I hope this help. Enjoy!
The Limba project does not only have the goal to allow developers to deploy their applications directly on multiple Linux distributions while reducing duplication of shared resources, it should also make it easy for developers to build software for Limba.
Limba is worth nothing without good tooling to make it fun to use. That s why I am working on that too, and I want to share some ideas of how things could work in future and which services I would like to have running. I will also show what is working today already (and that s quite something!). This time I look at things from a developer s perspective (since the last posts on Limba were more end-user centric). If you read on, you will also find a nice video of the developer workflow 
1. Creating metadata and building the software
To make building Limba packages as simple as possible, Limba reuses already existing metadata, like AppStream metadata to find information about the software you want to create your package for.
To ensure upstreams can build their software in a clean environment, Limba makes using one as simple as possible: The limba-build CLI tool creates a clean chroot environment quickly by using an environment created by debootstrap (or a comparable tool suitable for the Linux distribution), and then using OverlayFS to have all changes to the environment done during the build process land in a separate directory.
To define build instructions, limba-build uses the same YAML format TravisCI uses as well for continuous integration. So there is a chance this data is already present as well (if not, it s trivial to write).
In case upstream projects don t want to use these tools, e.g. because they have well-working CI already, then all commands needed to build a Limba package can be called individually as well (ideally, building a Limba package is just one call to lipkgen).
I am currently planning DeveloperIPK packages containing resources needed to develop against another Limba package. With that in place and integrated with the automatic build-environment creation, upstream developers can be sure the application they just built is built against the right libraries as present in the package they depend on. The build tool could even fetch the build-dependencies automatically from a central repository.
2. Uploading the software to a repository
While everyone can set up their own Limba repository, and the limba-build repo command will help with that, there are lots of benefits in having a central place where upstream developers can upload their software to.
I am currently developing a service like that, called LimbaHub . LimbaHub will contain different repositories distributors can make available to their users by default, e.g. there will be one with only free software, and one for proprietary software. It will also later allow upstreams to create private repositories, e.g. for beta-releases.
3. Security in LimbaHub
Every Limba package is signed with they key of its creator anyway, so in order to get a package into LimbaHub, one needs to get their OpenPGP key accepted by the service first.
Additionally, the Hub service works with a per-package permission system. This means I can e.g. allow the Mozilla release team members to upload a package with the component-ID org.mozilla.firefox.desktop or even allow those user(s) to own the whole org.mozilla.* namespace.
This should prevent people hijacking other people s uploads accidentally or on purpose.
4. QA with LimbaHub
LimbaHub should also act as guardian over ABI stability and general quality of the software. We could for example warn upstreams that they broke ABI without declaring that in the package information, or even reject the package then. We could validate .desktop files and AppStream metadata, or even check if a package was built using hardening flags.
This should help both developers to improve their software as well as users who benefit from that effort. In case something really bad gets submitted to LimbaHub, we always have the ability to remove the package from the repositories as a last resort (which might trigger Limba to issue a warning for the user that he won t receive updates anymore).
What works
Limba, LimbaHub and the tools around it are developing nicely, so far no big issues have been encountered yet.
That s why I made a video showing how Limba and LimbaHub work together at time:
Still, there is a lot of room for improvement Limba has not yet received enough testing, and LimbaHub is merely a proof-of-concept at time. Also, lots of high-priority features are not yet implemented.
LimbaHub and Limba need help!
At time I am developing LimbaHub and Limba alone with only occasional contributions from others (which are amazing and highly welcomed!). So, if you like Python and Flask, and want to help developing LimbaHub, please contact me the LimbaHub software could benefit from a more experienced Python web developer than I am 
The first updated in the 0.12.* series of 
I have finally finished the Portfile for 
Necessary steps:
It's time for some new music. And given that this artist was suggested to me at least twice by different people I guess I finally have to feature her. This time it's about 
Over the past few years, a plethora of 
Hm, wasn't there a 
I had the wonderful privilege to go camping and hiking with my kids scouting group, the Pathfinders of Tantallon SDA church. The day started with a quick trip to Pugwash with one of the leaders to bring back some chairs to their school, and then we headed back out to Blomidon to meet up with the group. Click the photo below to start the slideshow.
.
I have about 18 personal hosts, all running the Jessie release of Debian GNU/Linux. To keep up with security updates I use 
What happened in the 
I knew it was about this time of the year 10 years ago when my Debian account
was created, but I couldn't remember the exact date until I looked it up
earlier this evening: today :). Rene Engelhard had been my advocate, and Marc
Brockschmidt my AM. Thanks guys!
A lot of time has passed since then, and I've worked in various parts of the
project. I became an application manager almost immediately, and quickly got
into the NM front desk as well, revamping parts of the NM process which had
become pretty bureaucratic (I think we are now, 10 years later, back where we
should be, thanks to almost all of the paperwork being automated, thanks
Enrico!). I've processed 37 NMs, most of them between 2005 and 2008, later I
was only active as front desk and eventually Debian account manager. I've
recently picked up AMing again, which I still find quite refreshing as the AM
will always also learn new things.
Quality Assurance was and is the other big field. Starting by doing QA uploads
of orphaned packages, I attended some QA meetings around Germany, and picked up
maintenance of the DDPO pages, which I still maintain. The link between QA and
NM is the MIA team where I was active for some years until they kindly kicked
me out because I was MIA there myself. I'm glad they are still using some of
the scripts I was writing to automate some things.
My favorite MUA is mutt, of which I became co-maintainer in 2007, and later
maintainer. I'm still listed in the uploaders field, but admittedly I haven't
really done anything there lately.
Also in 2007 I started working at credativ, after having been a research
assistant at the university, which meant making my Debian work professional. Of
course it also meant more real work and less time for the hobby part, but I was
still very active around that time. Later in 2010 I was marrying, and we got
two kids, at which point family was of course much more important, so my Debian
involvement dropped to a minimum. (Mostly lurking on IRC ;)
Being a PostgreSQL consultant at work, it was natural to start looking into the
packaging, so I started submitting patches to postgresql-common in 2011, and
became a co-maintainer in 2012. Since then, I've mostly been working on
PostgreSQL-related packages, of which far too many have my (co-)maintainer
stamp on them. To link the Debian and PostgreSQL worlds together, we started an
external repository (apt.postgresql.org) that contains packages for the
PostgreSQL major releases that Debian doesn't ship. Most of my open source time
at the moment is spent on getting all PostgreSQL packages in shape for Debian
and this repository.
According to minechangelogs, currently 844 changelog entries in Debian mention
my name, or were authored by me. Scrolling back yields memories of packages
that are long gone again from unstable, or I passed on to other maintainers.
There are way too many people in Debian that I enjoy(ed) working with to list
them here, and many of them are my friends. Debian is really the extended
family on the internet. My last DebConf before this year had been in Mar del
Plata - I had met some people at other conferences like FOSDEM, but meeting
(almost) everyone again in Heidelberg was very nice. I even remembered all
basic Mao rules :D.
So, thanks to everyone out there for making Debian such a wonderful place to
be!
The C1 Server
