Echoes Corsac.net - Echoes camshot
mercredi 28 mars 2018 (2 posts)

There was some noise recently about the massive amount of data gathered by Cambridge Analytica from Facebook users. While I don't use Facebook myself, I do use Google and other services which are known to gather a massive amount of data, and I obviously know a lot of people using those services. I also saw some posts or tweet threads about the data collection those services do.

Mozilla recently released a Firefox extension to help users confine Facebook data collection. This addon is actually based on the containers technology Mozilla develops since few years. It started as an experimental feature in Nightly, then as a test pilot experiment, and finally evolved into a fully featured extension called Multi-Account containers. A somehow restricted version of this is even included directly in Firefox but you don't have the configuration window without the extension and you need to configure it manually with about:config.

Basically, containers separate storage (cookies, site preference, login session etc.) and enable an user to isolate various aspect of their online life by only staying logged to specific websites in their respective containers. In a way it looks like having a separate Firefox profile per website, but it's a lot more usable daily.

I use this extension massively, in order to isolate each website. I have one container for Google, one for Twitter, one for banking etc. If I used Facebook, I would have a Facebook container, if I used gmail I would have a gmail container. Then, my day to day browsing is done using the “default” container, where I'm not logged to any website, so tracking is minimal (I also use uBlock origin to reduce ads and tracking).

That way, my online life is compartmentalized/containerized and Google doesn't always associate my web searches to my account (I actually usually use DuckDuckGo but sometimes I do a Google search), Twitter only knows about the tweets I read and I don't expose all my cookies to every website.

The extension and support pages are really helpful to get started, but basically:

  • you install the extension from the extension page
  • you create new containers for the various websites you want using the menu
  • when you open a new tab you can opt to open it in a selected container by long pressing on the + button
  • the current container is shown in the URL bar and with a color underline on the current tab
  • it's also optionally possible to assign a website to a container (for example, always open facebook.com in the Facebook container), which can help restricting data exposure but might prevent you browsing that site unidentified

When you're inside the container and you want to follow a link, you can get out of the container by right clicking on the link, select “Open link in new container tab” then select “no container”. That way Facebook won't follow you on that website and you'll start fresh (after the redirection).

As far as I can tell it's not yet possible to have disposable containers (which would be trashed after you close the tab) but a feature request is open and another extension seems to exist.

In the end, and while the isolation from that extension is not perfect, I really suggest Firefox users to give it a try. In my opinion it's really easy to use and really helps maintaining healthy barriers on one's online presence. I don't know about an equivalent system for Chromium (or Safari) users but if you know about it feel free to point it to me.

A French version of this post is also available here just in case.

Yves-Alexis@20:44:03 (Debian)

La collecte de données d'utilisateurs Facebook par Cambridge Analytica a fait pas mal de bruit récemment. Je ne suis pas moi-même utilisateur de Facebook, mais j'utilise d'autres services comme ceux de Google, connus pour leur collecte massive de données utilisateurs, et je connais beaucoup de monde qui utilise Facebook quotidiennement. J'ai aussi vu passer des tweets de gens qui racontent la quantité de données personnelles collectées par ces services.

Mozilla a récemment publié une extension Firefox permettant d'aider les internautes à limiter la collecte de données par Facebook. Cette extension est en fait basée sur les containers (ou contextes), que Mozilla développe depuis plusieurs années. Ça a commencé par une fonctionnalité expérimentale dans la version en développement, puis comme une expérimentation test pilot jusqu'à devenir une extension complète nommée Multi-Account containers. Une version réduite sans interface de configuration est même intégrée directement dans Firefox.

Les containers Firefox séparent le stockage local des sites visités (cookies, préférences, sessions utilisateurs etc.) et permettent à un utilisateur d'isoler les différents pans de sa vie en ligne, en ne s'identifiant à un site que dans un « contexte » spécifique. Un peu comme en ayant un profil Firefox complet par site, mais en beaucoup plus pratique.

Personnellement j'utilise cette extension sans arrêt afin d'isoler les différents sites où je suis identifié. J'ai un contexte pour Google, un pour Twitter, un pour ma banque etc. Si j'utilisais Facebook j'en aurais un pour Facebook, si j'utilisais gmail j'en aurai un pour gmail. La navigation courante se fait dans le container « par défaut » où je ne suis jamais identifié à aucun site web, et où la collecte de données est donc plus minime (j'utilise aussi l'extension uBlock Origin pour limiter les pubs et le tracking).

Du coup, ma vie en ligne est compartimentée: Google n'associe pas chacune de mes requête à mon compte (par ailleurs j'utilise plutôt DuckDuckGo, Twitter ne connait que les tweets que je regarde et je n'expose pas tous mes cookies à tous les sites web.

Pour se servir de l'extension, la page de téléchargement ainsi que celle de support sont vraiment claires, mais globalement ça se passe comme ça:

  • on installe l'extension depuis la page, et on l'active ;
  • on crée de nouveaux contextes correspondant à son usage, via le menu de configuration ;
  • on ouvre un onglet dans un contexte spécial en cliquant longuement sur le + ou en utilisant contrôle+clic ;
  • le contexte courant est indiqué dans la barre d'URL ainsi que par un liseré de couleur sous l'onglet ;
  • optionnellement, on peut assigner un site à un contexte, et il s'ouvrira systématiquement dans ce contexte (par exemple facebook.com s'ouvrira systématiquement dans le contexte Facebook, ce qui est sans doute ce que fait l'extension récemment publiée par Mozilla); ça permet de restreindre l'exposition des données mais empêche par contre de regarder Facebook sans être identifié

Une fois à l'intérieur d'un contexte, on peut en sortir en faisant un clic droit sur un lien, en choisissant « Ouvrir dans un nouvel onglet contextuel » et en sélectionnant « Sans contexte ». De cette façon Facebook ne continuera pas le suivi dans le nouveau contexte.

Autant que je sache il n'est pas encore possible d'avoir des contextes jetables (détruits lors de la fermeture de l'onglet) mais une requête est ouverte à ce sujet et une autre extension semble exister.

Au final, et même si l'isolation n'est peut-être pas complète, je recommande fortement aux utilisateurs de Firefox d'essayer cette extension. Je la trouve vraiment simple d'utilisation et elle aide vraiment à conserver de saines frontières dans sa vie en ligne.

Je ne sais pas s'il existe un équivalent pour Chromium (ou Safari), mais si quelqu'un en connait n'hésitez pas à me l'indiquer.

Yves-Alexis@20:35:16 (Echoes)

jeudi 21 décembre 2017 (1 post)

Aujourd'hui les jours rallongent \o/

Corsac@08:18:07 (Echoes)

dimanche 26 novembre 2017 (1 post)

Bonne fête Delphine !

Corsac@08:16:54 (Roadbook)

lundi 16 octobre 2017 (1 post)

Following the news about the ROCA vulnerability (weak key generation in Infineon-based smartcards, more info here and here) I can confirm that the Almex smartcard I mentionned on my last post (which are Infineon based) are indeed vulnerable.

I've contacted Almex to have more details, but if you were interested in buying that smartcard, you might want to refrain for now.

It does *not* affect keys generated off-card and later injected (the process I use myself).

 

Yves-Alexis@17:32:01 (Debian)

mardi 10 octobre 2017 (1 post)

A long time ago, I switched my GnuPG setup to a smartcard based one. I kept using the same master key, but:

  • copied the rsa4096 master key to a “master” smartcard, for when I need to sign (certify) other keys;
  • created rsa2048 subkeys (for signature, encryption and authentication) and moved them to an OpenPGP smartcard for daily usage.

I've been working with that setup for a few years now and it is working perfectly fine. The signature counter on the OpenPGP basic card is a bit north of 5000 which is large but not that huge, all considered (and not counting authentication and decryption key usage).

One very nice feature of using a smartcard is that my laptop (or other machines I work on) never manipulates the private key directly but only sends request to the card, which is a really huge improvement, in my opinion. But it's also not the perfect solution for me: the OpenPGP card uses a proprietary platform from ZeitControl, named BasicCard. We have very few information on the smartcard, besides the fact that Werner Koch trust ZeistControl to not mess up. One caveat for me is that the card does not use a certified secure microcontroler like you would find in smartcard chips found in debit card or electronic IDs. That means it's not really been audited by a competent hardware lab, and thus can't be considered secure against physical attacks. The cardOS software and the application implementing the OpenPGP specification are not public either and have not been audited either, to the best of my knowledge.

At one point I was interested in the Yubikey Neo, especially since the architecture Yubico used was common: a (supposedly) certified platform (secure microcontroler, card OS) and a GlobalPlatform / JavaCard virtual machine. The applet used in the Yubikey Neo is open-source, too, so you could take a look at it and identify any issue.

Unfortunately, Yubico transitioned to a less common and more proprietary infrastructure for Yubikey 4: it's not longer Javacard based, and they don't provide the applet source anymore. This was not really seen as a good move by a lot of people, including Konstantin Ryabitsev (kernel.org administrator). Also, it wasn't possible  even for the Yubico Neo to actually build the applet yourself and inject it on the card: when the Yubikey leaves the facility, the applet is already installed and the smartcard is locked (for obvious security reason). I've tried asking about getting naked/empty Yubikey with developers keys to load the applet myself, but it' was apparently not possible or would have required signing an NDA with NXP (the chip maker), which is not really possible as an individual (not that I really want to anyway).

In the meantime, a coworker actually wrote an OpenPGP javacard applet, with the intention to support latest version of the OpenPGP specification, and especially elliptic curve cryptography. The applet is called SmartPGP and has been released on ANSSI github repository. I investigated a bit, and found a smartcard with correct specification: certified (in France or Germany), and supporting Javacard 3.0.4 (required for ECC). The card can do RSA2048 (unfortunately not RSA4096) and EC with NIST (secp256r1, secp384r1, secp521r1) and Brainpool (P256, P384, P512) curves.

I've ordered some cards, and when they arrived started playing. I've built the SmartPGP applet and pushed it to a smartcard, then generated some keys and tried with GnuPG. I'm right now in the process of migrating to a new smartcard based on that setup, which seems to work just fine after few days.

Part two of this serie will describe how to build the applet and inject it in the smartcard. The process is already documented here and there, but there are few things not to forget, like how to lock the card after provisionning, so I guess having the complete process somewhere might be useful in case some people want to reproduce it.

Yves-Alexis@22:44:37 (Debian)

jeudi 27 avril 2017 (1 post)

Since the question popped here and there, I'll post a short blog post about the issue right now so there's a reference somewhere.

As you may know, Brad Spengler (spender) and the Pax Team recently announced that the grsecurity test patches won't be released publicly anymore. The stable patches were already restricted to enterprise, paying customers, this is now also the case for the test patches.

Obviously that means the end of the current situation in Debian since I used those test patches for the linux-grsec packages, but I'm not exactly sure what comes next and I need to think a bit about this before doing anything.

The “passing the baton” post mention a handover to the community (though the FAQ mention it needs to stop using the term “grsecurity”) so maybe there's some coordination possible with other users like Gentoo Hardened and Alpine, but it's not clear what would be possible with the tools we have.

I'm actually quite busy right now so I don't have much time to think about all this, but expect a new blog post when things have settled a bit and I've made up my mind.

Yves-Alexis@13:18:57 (Debian)

mercredi 21 décembre 2016 (1 post)

Aujourd'hui les jours rallongent \o/

Corsac@12:03:55 (Roadbook)

samedi 26 novembre 2016 (1 post)

Bonne fête Delphine !

Corsac@12:03:31 (Roadbook)

mercredi 04 mai 2016 (1 post)

Following discussion in #810506 and the ACK by the backports team, I've uploaded linux-grsec package (version 4.4.7-1+grsec201604152208+1~bpo8+1) to jessie-backports, and it has been ACCEPTED this morning (along with linux-grsec-base support package). So if you have a Jessie install with backports enabled, linux-grsec should be one apt call away:

apt install -t jessie-backports linux-image-grsec-amd64

4.4.8 should follow soon

.

Yves-Alexis@10:45:35 (Debian)

samedi 09 janvier 2016 (1 post)

As some of you might have already noticed, linux-grsec entered Debian unstable earlier this week, following linux-grsec-base a bit earlier.

So that means, if you're running sid, you can just run:

# apt install linux-image-4.3.0-1-grsec-amd64

There's no metapackage (version-less) for now, but I might add one at one point, if people need it.

After installing the kernel and the linux-grsec-base support package, you should check the /etc/sysctl.d/grsec.conf file and review the various tunables there, which might or might not suit your needs. The settings are mostly all enabled in the package (in order to get a “secure by default” state), but there a few bits you might need to disable.

 For example, on my main laptop, where I do most of my stuff, including Debian work, I've disabled:

kernel.grsecurity.deny_new_usb = 0
kernel.grsecurity.audit_chdir = 0
kernel.grsecurity.chroot_deny_chmod = 0
kernel.grsecurity.chroot_deny_mknod = 0
kernel.pax.softmode = 0

The deny_new_usb because a laptop is not really usable without USB, audit_chdir because it's really to noisy (I like to keep exec_logging though, because it's only for the root gid so it's somehow interesting and not too noisy).

Both chroot settings are disabled because I'm building packages in pbuilder, which uses chroot. By the way, if you're doing that you'll need to add the pbuilder (uid 1234) user to the grsec-tpe (gid 64040) group inside the chroot so it has permissions to execute stuff.

softmode is disabled but it's a default setting (“secure by default”). You can use it if needed to see what PaX /would/ deny and adjust things (using paxctl or setting file extended attributes).

On the same laptop, I need to set PaX 'm' attributes (allow W|X memory maps) on the following binaries:

setfattr -n user.pax.flags -v m /usr/bin/evolution
setfattr -n user.pax.flags -v m /usr/bin/python
setfattr -n user.pax.flags -v m /usr/lib/chromium/chromium

It's a bit unfortunate (especially evolution and chromium are quite exposed to untrusted code, and python is really too generic), but to keep a working box I don't have much choice.

Plans regarding stable are a bit more fuzzy. As indicated on the initial bug, the current upstream release model doesn't really fit with the “Debian stable” one: only the test patch, against the latest major Linux kernel version, is available free of charge. I don't think the release team would be really happy to see a new Linux version uploaded to stable every two months.

Although having linux-grsec on unstable is already a great victory, I still think most users are likely to want it on stable (for example on server boxes), so I'm considering plans for that. Right now, I'm still uploading jessie packages to my repository, but also investigating wether backports are suitable. The default answer is no, obviously, because backports are only supposed to hosts packages which will be in the next stable release, but maybe there will be something possible. Stay tuned, in any way.

Don't hesitate to try the packages. There might be some roughs edges, it's expected. If you have issues, please read the documentation available on grsecurity and PaX, because security is a process, and installing the package won't just magically make you secure if you don't know what it does. Don't hesitate to report bugs, but try to investigate a bit before (with the src:linux package, and with vanilla+grsec packages).

Finally, many thanks to Brad Spengler and the PaX team, this is their work, I'm merely the packager here. 

Yves-Alexis@10:14:37 (Debian)

mardi 22 décembre 2015 (1 post)

Aujourd'hui les jours rallongent \o/

Corsac@20:33:55 (Roadbook)

jeudi 26 novembre 2015 (1 post)

Bonne fête Delphine !

Corsac@17:57:34 (Roadbook)

samedi 21 novembre 2015 (1 post)

Tout d'abord, un grand grand merci. Un grand merci à Caravan Palace, pour avoir joué hier soir, un grand merci au public pour avoir été si bon.

Lorsque <|°_°|> (oui je ne sais pas non plus comment le prononcer) est sorti, et que j'ai vu qu'il y avait un concert prévu à Paris, je me suis tout de suite dit que ça se tentait. Mais j'avais un peu zappé le truc, jusqu'à la sortie du concert d'Archive, où on s'est dit que quand même le live, c'était chouette. Malheureusement, à ce moment là, il n'y avait plus de places, et les places d'occasion s'arrachaient comme des petits pains, j'avais pratiquement renoncé à pouvoir y aller.

Fast-forward à la semaine dernière et les attentats du 13 novembre. Comme tout le monde, ça nous a bien secoué, et ça continue. On ne sait toujours pas trop comment vivre avec ça, comment avancer. Mais une des conséquences de ça, c'est que pas mal de gens ont commencé à revendre des places pour le concert. Sans trop réflechir, j'en ai récupéré deux. Pas par militantisme, pas par héroïsme mal placé, et avec tout de même un peu d'appréhension, soyons honnête.

Mais justement, sans verser dans le militantisme, s'il y a bien une chose qui semble importante, c'est justement de ne rien changer. Ni dans un sens, ni dans l'autre. Continuer, non pas comme si de rien n'était, on ne pourra pas oublier ce qu'il s'est passé, mais ne pas se laisser dicter ses réactions, ses actions, son mode de vie.

Alors voilà, hier soir, devant l'Olympia, on ne savait pas encore trop ce qui nous attendait, on était je pense tous un peu mi-figue, mi-raisin. En ayant tout de même conscience que ce soir, c'était spécial.

Première partie sympathique (Souleance), même si l'aspect live est un peu déconvertant (musique uniquement électronique, y compris les paroles, donc la présence scénique se résume un peu à une table avec deux laptops et deux geeks derrière). Puis arrive le moment attendu, et l'entrée en scène de Caravan Palace (après que l'Olympia nous offre gracieusement un entracte de vingt minutes, qui en dure plutôt trente).

Et là, c'est la folie, dès le début. J'ai perdu le fil de la setlist dès le début (j'essayerai de la retrouver à l'occasion), mais ça a commencé très très fort. Le publique a commencé à sautiller, à danser. Et ça a duré une bonne heure et demie, avec à peine le temps de se reposer. Ça rockait, ça swingait, sans s'arrêter.

Beaucoup d'émotion aussi. On sentait Zoé Colotis (la chanteuse) au bord des larmes, quand elle a dit bonjour au nom du groupe. Et à 21h20, une semaine pile après le début de l'attaque au Bataclan, moment spécial : elle nous demande un cri, un hurlement : pour ne pas oublier, pour montrer qu'on est là, pour repousser la haine, pour crier, tout simplement. Et toute la salle répond, hurle, se libère de ses démons.

Et ensuite c'est reparti, ça saute dans tous les sens. J'ai rarement ressenti une telle rage de vivre et de jouer de la part d'un groupe, et de son public. J'ai encore du mal à mettre des mots sur autant d'émotion, j'avoue.

Alors encore une fois merci à vous, j'ai passé une soirée merveilleuse, et je crois qu'on en avait tous besoin.

 

Corsac@15:13:27 (Echoes)

mercredi 04 novembre 2015 (1 post)

Thanks to Mehdi Dogguy, here's a nice hook to generate a source change file at build time (with pbuilder), so one can upload source-only packages to the archive and have buildds rebuild for all the architectures. Put it in .pbuilder/hooks/B10_source-build so it gets called once the builds succeeds

#! /bin/sh

generate_change_file()
{
  local version=$(dpkg-parsechangelog -Sversion)
  local package=$(dpkg-parsechangelog -Ssource)
  echo "Generating source changes file"
  dpkg-genchanges -S > ../${package}_${version}_source.changes
}

cd /tmp/buildd/*/debian/..
generate_change_file

Next time you build a package, you should find, alongside the <package>_<version>_<arch>.changes file, a <package>_<version>_source.changes which you can use with usual tools (lintian, debsign, dput…) to upload it to the Debian archive.

Note that if you do that, you have to make sure that your debian/rules support building separately the arch-dependent and arch-independant packages. To check that, you can call pdebuild like this:

pdebuild --debbuildopts -A # binary-only build, limited to arch-independant packages
pdebuild --debbuildopts -B # binary-only build, limited to arch-dependant packages

Yves-Alexis@20:53:55 (Debian)

dimanche 01 novembre 2015 (1 post)

Suite à un cadeau d'anniversaire (merci !), hier c'était soirée concert. Archive, une nouvelle fois, pour le Restriction tour 2015. La dernière foi c'était en 2012 (pour la tournée de With us until you're dead), et finalement ça passe vite. Depuis ils ont sorti Axiom et Restriction, qui faisaient donc assez logiquement la plus grosse part du concert.

Malheureusement (et comme en 2012, en fait), j'ai moyennement apprécié le rendu live des chansons interprétées par Holly Martin (la « nouvelle » chanteuse, arrivée au moment de With us until you're dead). Autant j'adore les versions studio (en particulier de Violently), autant j'accroche pas les arrangements live. Holly Martin était la seule chanteuse de ce concert (pas de Maria Q ce coup-ci), et en plus des chansons de Restrictions (un peu décevantes pour moi, donc) elle a chanté You make me feel (de Take my head), qu'elle a pour le coup merveilleusement réussi.

De façon générale, d'ailleurs, hormis la séquence ViolentlyKid korner, j'ai vraiment adoré les interprétations live. Y'avait du punch, ça bougeait bien quand il fallait, c'était doux quand il fallait, c'était mélodieux quand il fallait. Bref, du bonheur. Un peu fort (on a fini par se reculer, d'ailleurs), mais pas horrible (à la Massive Attack) non plus. Et j'ai beaucoup aimé la lumière aussi.

La setlist, donc :

  • Feel It
  • Fuck U
  • Dangervisit
  • Finding It So Hard
  • Crushed
  • Conflict
  • Violently
  • Black and Blue
  • End of Our Days
  • Kid Corner
  • You Make Me Feel
  • Bullets
  • Distorted Angels
  • Baptism
  • Ladders
  • Numb
  • Encore: Lights

Une grosse mention spéciale à DangervisitFinding it so hard (que j'apprécie moyennement en studio, pour le coup, mais qui a dépoté en live) et le Lights du rappel, qu'ils ont bien fait durer.

Dans l'ensemble, un très bon moment, une très bonne soirée <3

Corsac@15:56:45 (Roadbook)

mercredi 30 septembre 2015 (1 post)

As part of my ongoing effort to provide grsecurity patched kernels for Debian, I gave a talk this morning at Kernel Recipes 2015. Slides and video should be available at one point, but you can find the former here in the meantime. I'm making some progresses on #605090 which I should be able to push soon.

Yves-Alexis@18:00:09 (Debian)

dimanche 09 août 2015 (1 post)

So, everybody knows that WPS (Wi-Fi Protected Setup) is broken. But sometimes, you don't own the access point, and you'd just want the wireless to work. That happens for example when you're a guest in some place using an Orange Livebox and you don't have the WPA passphrase (usually because it's written somewhere you don't have access too, or because someone forgot to tell you).

Liveboxes WPS is the “press button” thing: you press a button on the front for one second, then any device can connect in the next two minutes. That works fine with Android devices, for example, but it didn't work with my laptop and NetworkManager, which doesn't support WPS at all.

Fortunately, the underlying piece of software (wpa_supplicant) does support WPS, and even the “push button” style. And you can nicely ask it to reveal the passphrase to you with the following trick.

  1. Disconnect NetworkManager from the network, disable the wireless link, stop it; just make sure wpa_supplicant is not running;
  2. Put a stub wpa_supplicant.conf file with only the following content:
    update_config=1
    
  3. Start wpa_supplicant in the foreground with your stub config file: 
    wpa_supplicant -iwlan0 -c wpa_supplicant.conf
    
  4. Start wpa_cli
Inside wpa_cli:
  1. Scan the network:
    scan
    
  2. Get the results:
    scan_results
    
    and identity the bssid of the Livebox
  3. Press the WPS button on the Livebox
  4. Run
    wps_pbc <bssid>
    ; some text should appear in the wpa_cli window, and it should eventually connect successfully (at that point you can even run a dhclient on wlan0)
  5. Run
    save_config
    

The last command will update your stub configuration file, adding a new network block with the passphrase in the clear. You can then use that passphrase inside Network Manager if it's more convenient for you.

There might be something easier, but at least it worked just fine for me during the holidays.

Yves-Alexis@21:44:32 (Debian)

jeudi 21 mai 2015 (1 post)

So, following the previous post, I've indeed updated the way I'm making my grsec kernels.

I wanted to upgrade my server to Jessie, and didn't want to keep the 3.2 kernel indefinitely, so I had to update to at least 3.14, and find something to make my life (and maybe some others) easier.

In the end, like planned, I've switched to the make deb-pkg way, using some scripts here and there to simplify stuff.

The scripts and configs can be found in my debian-grsec-config repository. The repository layout is pretty much self-explaining:

The bin/ folder contains two scripts:

  • get-grsec.sh, which will pick the latest grsec patch (for each branch) and applies it to the correct Linux branch. This script should be run from a git clone of the linux-stable git repository;
  • kconfig.py is taken from the src:linux Debian package, and can be used to merge multiple KConfig files

The configs/ folder contains the various configuration bits:

  • config-* files are the Debian configuration files, taken from the linux-image binary packages (for amd64 and i386);
  • grsec* are the grsecurity specifics bits (obviously);
  • hardening* contain non-grsec stuff still useful for hardened kernels, for example KASLR (cargo-culting nonwidthstanding) or strong SSP (available since I'm building the kernels on a sid box, YMMV).

I'm currently building amd64 kernels for Jessie and i386 kernels will follow soon, using config-3.14 + hardening + grsec. I'm hosting them on my apt repository. You're obviously free to use them, but considering how easy it is to rebuild a kernel, you might want to use a personal configuration (instead of mine) and rebuild the kernel yourself, so you don't have to trust my binary packages.

Here's a very quick howto (adapt it to your needs):

mkdir linux-grsec && cd linux-grsec
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git clone git://anonscm.debian.org/users/corsac/grsec/debian-grsec-config.git
mkdir build
cd linux-stable
../debian-grsec-config/bin/get-grsec.sh stable2 # for 3.14 branch
../debian-grsec-config/bin/kconfig.py ../build/.config ../debian-grsec-config/configs/config-3.14-2-amd64 ../debian-grsec-config/configs/hardening ../debian-grsec-config/configs/grsec
make KBUILD_OUTPUT=../build -j4 oldconfig
make KBUILD_OUTPUT=../build -j4 deb-pkg

Then you can use the generated Debian binary packages. If you use the Debian config, it'll need a lot of disk space for compilation and generate a huge linux-image debug package, so you might want to unset CONFIG_DEBUG_INFO locally if you're not interested. Right now only the deb files are generated but I've submitted a patch to have a .changes file which can be then used to manipulate them more easily (for example for uploading them a local Debian repository).

Note that, obviously, this is not targeted for inclusion to the official Debian archive. This is still not possible for various reasons explained here and there, and I still don't have a solution for that.

I hope this (either the scripts and config or the generated binary packages) can be useful. Don't hesitate to drop me a mail if needed.

Yves-Alexis@22:36:11 (Debian)

samedi 09 mai 2015 (1 post)

So, following the Jessie release, and after a quick approval by the release team for the 4.12 transition, we've uploaded Xfce 4.12 to sid and have asked the RT to schedule the relevant binNMUs for the libxfce4util and xfce4-panel reverse dependencies.

It went apparently well (besides some hickups here and there, lilke some lag on sparc, and some build-failulres on hurd). So Xfce 4.12 is now in sid, and should migrate to Stretch in the following weeks, provided nothing release critical is found.

Yves-Alexis@21:05:55 (Debian)

Images
Stats
  • 1510 posts
  • 5970 jours
  • 0.25 posts/jour
  • IRC
  • Last.fm
Stuff
Gallery
Tech
Webcomics
Weblogs
Desktop