lxc remote add lco https://images.linuxcontainers.org:8443

  adt-run libpng --- lxd lco:ubuntu/trusty/i386
  adt-run libpng --- lxd lco:debian/sid/amd64

  adt-run libpng --- ssh -s maas -- \
     --acquire "arch=amd64 tags=touchscreen" -r wily \
     http://my.maas.server/MAAS 123DEADBEEF:APIkey

  adt-run --apt-pocket=proposed=src:foo,libbar1,libbar-data ...

Changes in RcppArmadillo version 0.6.400.2.0 (2015-12-15)

• Upgraded to Armadillo 6.400.2 ("Flying Spaghetti Monster Deluxe")
  • expanded each_col(), each_row() and each_slice() to handle C++11 lambda functions
  • added ind2sub() and sub2ind()
  • fixes for corner cases in gmm_diag class

Changes in RcppArmadillo version 0.6.300.2.2 (2015-12-12)

• Upgraded to Armadillo 6.300.3-test ("Flying Spaghetti Monster")
  • Additional test in auxlib_meat.hpp for limited LAPACK
• Updated test and #define for limited LAPACK version R might be built with on Unix-alike systems

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

1. use 2FA on important websites like Github, to improve the security of critical infrastructure (like my Borg backup software)
2. login to remote SSH servers without exposing my password or my private key material on third party computers
3. store OpenPGP key material on the key securely, so that the private key material can never be compromised

• PIV (Personnal Identity Verification): basically to run your own Certificate Authority
• OTP (One Time Password): allows sites to request a OTP from a Yubikey server validator. I haven't explored that mode since it requires a third party server and more modifications on the server side.
• OATH (Initiative for Open Authentication): a purely "offline" and more "traditionnal" approach to OTP. In this mode, you can authenticate with only the token given by the key and a shared secret. Maybe i will follow this OATH tutorial eventually.

Not recommended After experimenting with the device and doing a little more research, I am not sure it was the right decision to buy a Yubikey. I would not recommend buying Yubikey devices because they don't allow changing the firmware, making the device basically proprietary, even in the face of an embarrassing security vulnerability on the Yubikey NEO that came out in 2015. A security device, obviously, should be as open as the protocols it uses, otherwise it's basically impossible to trust that the crypto hasn't been backdoored or compromised, or, in this case, is vulnerable to the simplest drive-by attacks. Furthermore, it turns out that the primary use case that Github was promoting is actually not working as advertised: to use the Yubikey on Github, you actually first need to configure 2FA with another tool, either with your phone's text messages (SMS) or with something like Google Authenticator. After contacting Github support, they explained that the Yubikey is seen as a "backup device", which seems really odd to me, especially considering the promotion and the fact that I don't have a "smart" (aka "Google", it seems these days) phone or the desire to share my personal phone number with Github. Finally, as I mentioned before, the fact that those devices are fairly new and the configuration necessary to make them work at all is completely obtuse, non-standardized or at least not available by default on arbitrary computers makes them basically impossible to use on other computers than your own specially crafted gems.

Plugging it in The Yubikey, when inserted into a USB port, seems to be detected properly. It shows up both as a USB keyboard and a generic device.

d c 14 17:23:26 angela kernel: input: Yubico Yubikey NEO OTP+U2F as /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2:1.0/0003:1050:0114.0016/input/input127
d c 14 17:23:26 angela kernel: hid-generic 0003:1050:0114.0016: input,hidraw3: USB HID v1.10 Keyboard [Yubico Yubikey NEO OTP+U2F] on usb-0000:00:12.0-2/input0
d c 14 17:23:26 angela kernel: hid-generic 0003:1050:0114.0017: hiddev0,hidraw4: USB HID v1.10 Device [Yubico Yubikey NEO OTP+U2F] on usb-0000:00:12.0-2/input1

We'll be changing this now - we want to to support OTP, U2F and CCID. Don't worry about those acronyms now, but U2F is for the web, CCID is for GPG/SSH, and OTP is for the One Time Passwords stuff mentionned earlier. I am using the Yubikey Personalization tool from stretch because the jessie one is too old, according to Gorzen. Indeed, I found out that the jessie version doesn't ship with the proper udev rules. Also, note that we need to run as sudo otherwise we get a permission denied:

$ sudo apt install yubikey-personalization/stretch
$ sudo ykpersonalize -m86
Firmware version 3.4.3 Touch level 1541 Program sequence 1
The USB mode will be set to: 0x86
Commit? (y/n) [n]: y

To understand better what the above does, see the NEO composite device documentation. The next step is to reconnect the key, for the udev rules to kick in. If you were like me, you enthusiastically plugged in the device before installing the yubikey-personalization package, and the udev rules were not present then.

Configuring a PIN Various operations will require you to enter a PIN when talking to the key. The default PIN is 123456 and the default admin PIN is 12345678. You will want to change that, otherwise someone that gets a hold of your key could do any operation without your consent. For this, you need to use:

$ gpg --card-edit
> passwd
> admin
> passwd

Be sure to remember those passwords! Of course, the key material on the Yubikey can be revoked when you loose the key, but only if you still have control of the master key, or if you have a OpenPGP revocation certification (which you should have).

Configuring GPG To do OpenPGP operations (like decryption, signatures and so on), or SSH operations (like authentication on a remote server), you need to talk with GPG. Yes, OpenPGP keys are RSA keys that can be used to authenticate with SSH servers, that's not new and I have already been doing this with Monkeysphere for a while. Now the challenge is how to make GPG talk with the Yubikey. So the next step is to see if gpg can see the key alright, as described in the Yubikey importing keys howto - you will need first to install scdaemon and pcscd (according to this howto) for gpg-agent to be able to talk with the key:

$ sudo apt install scdaemon gnupg-agent pcscd
$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
ERR 100663404 Card error <SCD>

Well that failed. At this point, touching the key types a bunch of seemingly random characters wherever my cursor is sitting - fun but totally useless still. That was because I failed to reconnect the key: make sure the udev rules are in place and reconnect the key, the above should work:

$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
D[0000]  01 00 10 90 00                                     .....
OK

This shows it is running the firmware 1.10, which is not vulnerable to the infamous security issue. (Note: I also happened to install opensc and gpgsm because of this suggestion but I am not sure they are required at all.)

Using SSH To make GPG work with SSH, you need somehow to start gpg-agent with ssh support, for example with:

gpg-agent --daemon --enable-ssh-support bash

Of course, this will work better if it's started with your Xsession. Such an agent should already be started, so you just need to add the ssh emulation to its configuration file and restart your X session.

echo 'enable-ssh-support' >> .gnupg/gpg-agent.conf

In Debian Jessie, the ssh-agent wrapper will not start if it detects that you have already one running (for example from gpg-agent) but if that fails, you can try commenting out use-ssh-agent from /etc/X11/Xsession.options to keep it from starting up in your session. (Thanks to stackexchange for that reference.) Here I assume you have already created an authentication subkey on your PGP key. If you haven't, I suggest trying out simply monkeysphere gen-subkey, which will generate an authentication subkey for you. You can also do it by hand by following one of the OpenPGP/SSH tutorials from Yubikey, especially the more complete one. If you are going to generate a completely new OpenPGP key, you may want to follow this simpler tutorial here. Then you need to move your authentication subkey to the Yubikey. For this, you need to edit the key and use the keytocard command:

$ gpg2 --edit-key anarcat@debian.org
> toggle
> key 2
> keytocard
> save

Here, we use toggle to show the OpenPGP private key material. You should see a key marked with A for Authentication. Mine was the second one so I selected it with key 2 which put a star next to it. The keytocard command moved it to the key and save ensure the key was removed from the local keyring. Obviously, backups are essential before doing this, because it's perfectly possible to loose that key in the process, for example if you destroy or lose the key or forget the password. It's probably better to create a completely different authentication subkey for just this purpose, but that may require reconfiguring all remote SSH hosts, and you may not want to do that. Then SSH should magically talk with the GPG agent and ask you for the PIN! That's pretty much all there is to it - if it doesn't, it means that gpg-agent is not your SSH agent, and obviously things will fail... Also, you should be able to see the key being loaded in the agent when it is:

$ ssh-add -l
2048 23:f3:be:bf:1e:da:e8:ad:4b:c7:f6:60:5e:03:c2:a6 cardno:000603647189 (RSA)

.. that's about it! I have yet to cover 2FA and OpenPGP support, but that got me going for a while and I'll stop geeking around with that thing for now. It was fun, for sure, but not sure it's worth it for now.

Using OATH This is pretty neat: it allows you to add two factor authentication to a lot of things. For example, PAM has such a module, which I will configure here to allow myself to login to my server from untrusted machines. While I will expose my main password to keyloggers, the OTP password will prevent that from being reused. This is a simplified version of this OATH tutorial. We install the PAM module with:

sudo apt install libpam-oath

Then, we can hook it into any PAM consumer, for example with sshd:

--- a/pam.d/sshd
+++ b/pam.d/sshd
@@ -1,5 +1,8 @@
 # PAM configuration for the Secure Shell service
+# for the yubikey
+auth required pam_oath.so usersfile=/etc/users.oath window=5 digits=8
+
 # Standard Un*x authentication.
 @include common-auth

We also needed to allow OTP passwords in sshd explicitely, with:

ChallengeResponseAuthentication yes

This will force the user to enter a valid oath token on the server. Unfortunately, this will affect all users, regardless of whether they are present in the users.oath file. I filed bug #807990 regarding this, with a patch. Also, it means the main password is still exposed on the client machine - you can use the sufficient keyword instead of required to workaround that, but then it means anyone with your key can login to your machine, which is something to keep in mind. The /etc/users.oath file needs to be created with something like:

#type   username        pin     start seed
HOTP    anarcat -   00

00 is obviously a fake, and insecure string. Generate a proper one with:

dd if=/dev/random bs=1k count=1   sha1sum # create a random secret

Then the shared secret needs to be added to the Yubikey:

ykpersonalize -1 -o oath-hotp -o oath-hotp8 -o append-cr -a

You simply paste the random secret you created above, when prompted, and that shared secret will be saved in a Yubikey slot for future use. Next time you login to the SSH server, you will be prompted for a OATH password, you just touch the button on the key and it will be pasted there:

$ ssh -o PubkeyAuthentication=no anarc.at
One-time password (OATH) for  anarcat':
Password:
[... logged in!]

Final note: the centralized file approach makes it hard, if not impossible, for users to update their own secret token.. It would be nice if there would be a user-accessible token file, maybe ~/.oath? Filed feature request #807992 about this as well.

• mailing list: debian-qa@lists.debian.org
• IRC: #debian-qa on OFTC. Feel free to highlight terceiro

• mailing list: autopkgtest-devel@lists.alioth.debian.org
• IRC: #debci on OFTC

Changes in Rblpapi version 0.3.2 (2015-12-07)

• A new subscribe() function supports live data subscription for a set of tickers and fields (#88).
• In the beqs() example the correct date format is used (PR #85 by Rademeyer).
• Both getTicks() and getBars() now check the start and end times for proper Datetime class.
• The getBars() function now also return the value traded (request of #89).
• An error in the documentation for bdh was corrected (PR #93 by Rademeyer closing #85).
• The beqs() function is now more robust with respect to empty return columns (PR #100 by Rademeyer fixing ticket #99).
• The getBars() function now uses a single (named) vector options to pass optional values to the underlying function (PR #105 updating PR #48 and fixing #47).
• When R is built with libcurl support, it used to download the build-time library and headers; otherwise curl is used. This avoids an issue on OS X where curl is insufficient.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Cookie Expiry Cookies are sent from the website to your browser via a Set-Cookie HTTP header on the response. It looks like this:

HTTP/1.1 200 OK
Date: Mon, 07 Dec 2015 16:55:43 GMT
Server: Apache
Set-Cookie: SESSIONID=65576c6c64206e6f2c657920756f632061726b636465742065686320646f2165
Content-Length: 2036
Content-Type: text/html;charset=UTF-8

When your browser sees this, it saves that cookie for the given hostname and keeps it until you close the browser. Should a site want to persist their cookie for longer, they can add an Expires attribute:

Set-Cookie: SESSIONID=65576c...; expires=Tue, 06-Dec-2016 22:38:26 GMT

in which case the browser will retain the cookie until the server-provided expiry date (which could be in a few years). Of course, that's if you don't instruct your browser to do things differently.

Controlling Cookie Expiry In order to change your cookie settings, you must open the Firefox preferences, click on "Privacy" and then choose "Use custom settings for history" under the "History" heading. There, you will have the ability to turn off cookies entirely (network.cookie.cookieBehavior = 2), which I don't recommend you do in your browser since you won't be able to login anywhere. On the other hand, turning off cookies is what I do (and recommend) in Thunderbird since I can't think of a legitimate reason for an email to leave a cookie in my mail client. Another control you'll find there is "Keep until" which defaults to honoring the server-provided expiry ("they expire" aka network.cookie.lifetimePolicy = 0) or making them expire at the end of the browsing session ("I close Firefox" aka network.cookie.lifetimePolicy = 2). A third option is available if you type about:config into your URL bar and looking for the network.cookie.lifetimePolicy preference. Setting this to 3 will honor the server-provided expiry up to a maximum lifetime of 90 days. You can also make that 90 days be anything you want by changing the network.cookie.lifetime.days preference. Regardless of the settings you choose, you can always tell Firefox to clear cookies when you close it by selecting the "Clear history when Firefox closes" checkbox, clicking the "Settings" button and making sure that "Cookies" is selected (privacy.clearOnShutdown.cookies = true). This could be useful for example if you'd like to ensure that cookies never last longer than 5 days but are also cleared whenever you shut down Firefox.

Third-Party Cookies So far, we've only looked at first-party cookies: the ones set by the website you visit and which are typically used to synchronize your login state with the server. There is however another kind: third-party cookies. These ones are set by the third-party resources that a page loads. For example, if a page loads JavaScript from a third-party ad network, you can be pretty confident that they will set their own cookie in order to build a profile on you and serve you "better and more relevant ads".

Controlling Third-Party Cookies If you'd like to opt out of these, you have a couple of options. The first one is to turn off third-party cookies entirely by going back into the Privacy preferences and selecting "Never" next to the "Accept third-party cookies" setting (network.cookie.cookieBehavior = 1). Unfortunately, turning off third-party cookies entirely tends to break a number of sites which rely on this functionality (for example as part of their for login process). A more forgiving option is to accept third-party cookies only for sites which you have actually visited directly. For example, if you visit Facebook and login, you will get a cookie from them. Then when you visit other sites which include Facebook widgets they will not recognize you unless you allow cookies to be sent in a third-party context. To do that, choose the "From visited" option (network.cookie.cookieBehavior = 3). In addition to this setting, you can also choose to make all third-party cookies automatically expire when you close Firefox by setting the network.cookie.thirdparty.sessionOnly option to true in about:config.

Other Ways to Limit Third-Party Cookies Another way to limit undesirable third-party cookies is to tell the browser to avoid connecting to trackers in the first place. This functionality is now built into Private Browsing mode and enabled by default. To enable it outside of Private Browsing too, simply go into about:config and set privacy.trackingprotection.enabled to true. You could also install the EFF's Privacy Badger add-on which uses heuristics to detect and block trackers, unlike Firefox tracking protection which uses a blocklist of known trackers.

My Recommended Settings On my work computer I currently use the following:

network.cookie.cookieBehavior = 3
network.cookie.lifetimePolicy = 3
network.cookie.lifetime.days = 5
network.cookie.thirdparty.sessionOnly = true
privacy.trackingprotection.enabled = true

which allows me to stay logged into most sites for the whole week (no matter now often I restart Firefox Nightly) while limiting tracking and other undesirable cookies as much as possible.

Bad People do bad things; a sexist is a wife-beater or sexual assailant; I am neither; therefore I am a Good Person and the things I do are good; I work on free software where people report sexist biases; therefore they say I am a wife-beater or sexual assailant; this is a false and ridiculous claim; therefore they are bad.

Changes in RcppArmadillo version 0.6.300.2.0 (2015-12-03)

• Upgraded to Armadillo 6.300.2 ("Flying Spaghetti Monster")
  • expanded solve() to find approximate solutions for rank-deficient systems
  • faster handling of non-contiguous submatrix views in compound expressions
  • added .for_each() to Mat, Row, Col, Cube and field classes
  • added rcond() for estimating the reciprocal condition number
  • fixes for spsolve(), eigs_sym(), eigs_gen(), svds()
• Added support for Cube types via as<> converters (PR #64 by Nathan Russell, fixing #63 and #42)

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Changes in RQuantLib version 0.4.2 (2015-12-03)

• Changes in RQuantLib code:
  • Intra-day times are now available if QuantLib 1.7 or later is used, and has been configured with --enable-intraday
  • New helper functions getQuantLibVersion() and getQuantLibCapabilties()
  • New package startup code detects and warns about outdated QuantLib versions, or missing intra-day capability, unless not interactive.
  • The missing Monthly parameter has been added to matchFrequency (fixing issue ticket #19)

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

[...]
I wonder if there are any active members of the Debian linux-ha team.
[...]

• pacemaker: https://tracker.debian.org/pkg/pacemaker
• corosync: https://tracker.debian.org/pkg/corosync

Changes in version 0.0.2 (2015-12-02)

• Additional #ifdef statements suggested by Bradley White in CCTZ ticket #5 permitting compilation on Solaris with thanks to Jeroen for testing our branch.

Changes in version 0.0.1 (2015-12-01)

• Initial CRAN upload.
• Package is functional and provides examples.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

• diffie-hellman-group14-sha1 key exchange (mostly by Ian Moore, finished off by me)
• diffie-hellman-group-exchange-sha256 key exchange
• hmac-sha2-256 and hmac-sha2-512 MACs

1. Recycled several ancient machines migrating services off of them while consolidating them by placing all their configuration on our central configuration management platform ran by Puppet. This includes a grand total of 7 machines that were replaced by new hardware and extended warranties the Foundation kindly sponsored.
2. We strenghten our websites security by introducing SSL certificates everywhere and recently replacing them with SHA2 certificates.
3. We introduced several services such as Owncloud, the Commits Bot, the Pastebin, the Etherpad, Jabber, the GNOME Github mirror.
4. We restructured the way we backup our machines also thanks to the Fedora Project sponsoring the disk space on their backup facility. The way we were used to handle backups drastically changed from early years where a magnetic tape facility was in charge of all the burden of archiving our data to today where a NetApp is used together with rdiff-backup.
5. We upgraded Bugzilla to the latest release, a huge thanks goes to Krzesimir Nowak who kindly helped us building the migration tools.
6. We introduced the GNOME Apprentice program open-sourcing our internal Puppet repository and cleansing it (shallow clones FTW!) from any sensitive information which now lives on a different repository with restricted access.
7. We retired Mango and our OpenLDAP instance in favor of FreeIPA which allows users to modify their account information on their own without waiting for the Accounts Team to process the change.
8. We documented how our internal tools are customized to play together making it easy for future Sysadmin Team members to learn how the infrastructure works and supersede existing members in case they aren t able to keep up their position anymore.
9. We started providing hosting to the GIMP and GTK projects which now completely rely on the GNOME Infrastructure. (DNS, email, websites and other services infrastructure hosting)
10. We started providing hosting not only to the GIMP and GTK projects but to localized communities as well such as GNOME Hispano and GNOME Greece
11. We configured proper monitoring for all the hosted services thanks to Nagios and Check-MK
12. We migrated the IRC network to a newer ircd with proper IRC services (Nickserv, Chanserv) in place.
13. We made sure each machine had a configured management (mgmt) and KVM interface for direct remote access to the bare metal machine itself, its hardware status and all the operations related to it. (hard reset, reboot, shutdown etc.)
14. We upgraded MoinMoin to the latest release and made a substantial cleanup of old accounts, pages marked as spam and trashed pages.
15. We deployed DNSSEC for several domains we manage including gnome.org, guadec.es, gnomehispano.es, guadec.org, gtk.org and gimp.org
16. We introduced an account de-activation policy which comes into play when a contributor not committing to any of the hosted repositories at git.gnome.org since two years is caught by the script. The account in question is marked as inactive and the gnomecvs (from the old cvs days) and ftpadmin groups are removed.
17. We planned mass reboots of all the machines roughly every month for properly applying security and kernel updates.
18. We introduced Mirrorbrain (MB), the mirroring service serving GNOME and related modules tarballs and software all over the world. Before introducing MB GNOME had several mirrors located in all the main continents and at the same time a very low amount of users making good use of them. Many organizations and companies behind these mirrors decided to not host GNOME sources anymore as the statistics of usage were very poor and preferred providing the same service to projects that really had a demand for these resources. MB solved all this allowing a proper redirect to the closest mirror (through mod_geoip) and making sure the sources checksum matched across all the mirrors and against the original tarball uploaded by a GNOME maintainer and hosted at master.gnome.org.

$ cd /git/GNOME/puppet && git shortlog -ns
3520 Andrea Veri
506 Olav Vitters
338 Owen W. Taylor
239 Patrick Uiterwijk
112 Jeff Schroeder
71 Christer Edwards
4 Daniel Mustieles
4 Matanya Moses
3 Tobias Mueller
2 John Carr
2 Ray Wang
1 Daniel Mustieles Garc a
1 Peter Baumgarten

mysql> select count(*) from Tickets where LastUpdatedBy = '52388';
+----------+
  count(*)  
+----------+
  3613  
+----------+
1 row in set (0.01 sec)
mysql> select count(*) from Tickets where LastUpdatedBy = '52388' and Status = 'Resolved';
+----------+
  count(*)  
+----------+
  1596  
+----------+
1 row in set (0.03 sec)