You are here

Bits from Debian

Subscribe to Feed Bits from Debian
Planet Debian - https://planet.debian.org/
Përditësimi: 2 ditë 21 orë më parë

Shirish Agarwal: No country for women – rehashed

Dje, 01/12/2019 - 10:20md

This is not the first time I am writing about it, sadly I had written it twice before in the preceding months. But the scenario instead of changing for the better is changing for the worse. Sharing a screenshot shared by somebody today on social-media.

Indian Express page inside page screenshot Page 9, Decamber 1, 2019 Reportage of Rape only.

The most recent gruesome addition to the list was that of a 26 year-old veterinarian. From the various news reports it was a pre-planned rape and murder of the woman. What was startling to me when I read the report that it seems people still either don’t know or police officers who should know and inform people do not inform people of their rights such as zero FIR . Maybe some RTI activist can find out how many people have used zero FIR or not and make efforts to popularize the concept and its utility. If people are courageous enough, they can even live-shoot video when asking a police officer or constable to file a zero FIR . The other part is I do hope the police do investigate and do the DNA matching so they have conclusive proof other than the statements which the rapists may later claim as being under duress. The views of police is almost Victorian in nature irrespective of whether it’s an officer or a lower hawaldar/constable on the beat.

While there have been many attempts to try and figure out solutions, it somehow always falls short. There was the ‘Occupy streets by women’ movement in 2017 and so many small and major attempts but almost all have fallen short. Simply put, neither the society, nor the police or the judiciary seems to have any answers. I probably had shared about India’s Daughter , a documentary which shared an insight into the rapist’s mindset. Except for the juvenile, all the other rapists who had confessed to the crime shared their opinion on why the rape happened and most of it was victim-blaming or victim-shaming. The producer Leslee Udwin at the time she made and released the documentary shared that she herself had been raped. The statements made by various BJP leaders as well as some from the opposition were so in favor of the men who had committed the rape were such that they had to finally ban the documentary as lot of hypocricy was being unveiled.

From 2012, till date there probably would be a dozen or more apps. which are designed to help somehow never work. There have been few women cab services, driven by women for women but that too has not scaled. The couple I know of are kaola kabs based out of Bangalore and women cabs in Delhi . The problem with Kaola is that they don’t have night services when most of the rapes occur and when they are needed, about womencabs maybe somebody who may have used the services could perhaps share their their experience. There have been many experiments, right from 2012 onwards but more often than not, most have been more or less a failure. The problems stem from many systemic and societal problems. The problem is not just of women but men too. Places which are unsafe for women are unsafe for all vulnerable groups, whether it is children, the elderly and anybody else who is not a bully. This simple understanding somehow fails to connect or be understood by people. We had this happen everywhere, whether in Bollywood or whether they are women cops or the judiciary. The situation for women is the same everywhere. And before somebody accuses me of India-bashing even though I live here. We know the same happens in all countries, surprisingly more in European countries where I expected human rights to be a savior but it seems they have their own fights to win. I guess if you are a predator you can find your prey no matter what your race or orientation is as shared by a victim recently.

Sex Education

While we can’t take the excuse of Sex education, the short video does illustrate the views of most people. If they don’t want to be responsible about children’s understanding and influence about sex especially in the nuclear families most are, then who will ?

https://www.invidio.us/watch?v=feQocm2TSBc

I had to look back at how I had helped Dr. Shome in her book where we had gone back and forth on her book on sex education titled ‘Let’s talk about guys, girls and sex’ which is there on Amazon, Kindle and elsewhere. My discussions as well as discussions with others, she had shared when last we met that she had material for at least another 2 books if she decided to go that way. The problem even with that such books do not make for casual reading and nor would either most parents or schools will attempt to have discussions around a book like that.

Mobile application for women safety

There are attempts to make a mobile application but I don’t see how any mobile application can help when it’s society’s issues at large. I am guessing funding is also going to be a big issue as well as transportation of people from place X to Y itself carries a cost other than costs and expenses incurred at various places.

Ancedote

I can share an anecdotal tale I heard from a gentleman couple of years ago, and like many stories or incidents this one also didn’t make the newspaper. A few years ago, I had gone to a friend’s place who was staying at Baner, at a somewhat secluded place. We used to meet for talking about FOSS, sharing foss, eating, drinking and sleeping at his place at night and next morning having a chai before using public transport to come back. We used to do this once a month or once two months till he shifted to Bangalore. Anyways, one night after partying I didn’t sleep well and went outside to the bus station quite early, around 0600 hrs or something like that. There used to be quite a few cycle rickshaw shops ( similar to food carts that you see in the west but somewhat more rundown.) The thing about Baner and the area I was in, this was factory area so most factories have 3-4 shifts so most of these food carts (called thelas in the vernacular) make brisk business. Unlike other times, instead of 3-4 food carts, I saw only one and also a bit of eerie silence. After a bit of talking, cajoling the owner, came to know that a naked woman had come and created a scene and other thela walas had run away. Whether she was mentally unstable or had she been raped was not known. Even the police jeep for some reason didn’t want to take her as they suspected they may blame the policeman. Even he had run away but as he was old he couldn’t tow the food cart so he simply ran away because in his twilight he didn’t want to get into any such complication.

The reason I shared the above is, in such a scenario how are men supposed to act and react, I don’t know. Whether it’s just fight or flight or some other behavioral patterns that should be incultated by men in such a scenario ?

Anthillhacks

FWIW, there is anthillhacks happening in Bangalore. For people interested in hacking or doing something like above, this may be a good chance to connect with like-minded people and have some sort of rough prototype out or at least hash out much more face-to-face rather than using the web. I had been a part of this just as have been part of similar things in the past and my experience has been swell. Unfortunately travel budget is an issue this year otherwise for sure would have been part of it. Hopefully people enjoy and also blog about their experiences while staying there.

Thorsten Alteholz: Debian-Med Bug Squashing

Dje, 01/12/2019 - 8:08md

As it is again this time of the year, I would also like to draw some attention to the Debian Med Advent Calendar. Like the past years, the Debian Med team starts a bug squashing event from the December 1st to 24th. Every bug that is closed will be registered in the calendar. So instead of taking something from the calendar, this special one will be filled and at Christmas hopefully every Debian Med related bug is closed. Don’t hestitate, start to squash :-).

The announcement on the mailing list can be found here.

Sam Hartman: Voting Guide for Debian Init Systems GR

Dje, 01/12/2019 - 6:22md

There are a lot of options on the ballot for the Init Systems GR.
There have been hundreds of messages on debian-vote, and more scattered
across debian-devel, debian-project, and bugs. Reading all that is no
easy task. so I would like to summarize my understanding of the options
and what they would mean. I've tried to remove as much bias as I can,
but this is still Sam's personal opinion.



I'm focused entirely on the effects of the proposals. Several options
(D, F, and G) spend significant time outlining principles. That is
something I'm ignoring here in this post, although I acknowledge it is
really important to some.



Areas of Agreement

One of the big surprises for me in this discussion is things that are
true of all the ballot options so far. We are agreed that programs
designed to use systemd features that only work with systemd are welcome
in Debian. That's true even if there is no way for these programs to
work without systemd. Under Proposal D, this is a bug, but not a
release-critical bug.



Init Diversity Options

Several options focus on encouraging or requiring packages to support
init systems others than systemd when that is possible. These include
Proposal
E
, Proposal F,
and Proposal
A
. Under proposal E, it is a release critical bug if a program does
not work when something other than systemd is pid 1 unless that program
is designed explicitly to work with systemd and no support for running
without systemd is available. Lack of an init script alone is not
sufficient to count as designed to work exclusively with systemd.



So, under this proposal, a maintainer must integrate support for running
without systemd if it is available. They are responsible for going out
and finding this support. If the support is as simple as writing an
init script, the maintainer has an RC bug until they write the init
script. If the support is more complex, the maintainer is not
responsible for writing it. Proposal A is the same as Proposal E,
except that the bug is not release-critical. I'll go into Proposal A in
more detail after discussing Proposal D.



Proposal D is similar to Proposal E. My interpretation is that Proposal D places
somewhat less of a burden on maintainers to go out and find existing
non-systemd support. My interpretation is that the bug becomes RC when
someone contributes that support. (Or if the support is present in the
upstream but turned off in the package). Proposal D requires that
non-systemd support not have a substantial effect on systemd
installations. So where as Proposal E uses the designed exclusively for
systemd criteria, Proposal D uses the no substantial effect on systemd
systems criteria to determine whether working only with systemd is
acceptable. The discussions seemed to imply that if Gnome uses systemd
features in excess of what technologies like elogind can handle, it is
likely to meet both criteria.



Proposal D goes into a lot more detail than Proposal E. Proposal E
would likely be a long-term block on using systemd facilities like
sysusers. Proposal D specifically proposes a mechanism whereby such
facilities can be documented in policy. This mechanism is only
available if it is likely that developers of non-systemd (including
non-Linux) systems will implement the facility. After a six-to-twelve
month transition time, the facility can be used even on non-systemd
systems. So, sufficiently low effort in the non-systemd community that
it is unreasonable to expect a facility could be implemented could still
permanently block adoption of such facilities. Proposal D is definitely
about a long-term commitment to non-systemd systems even if the effort
in the non-systemd community is not as high as we'd like to adopt new
features elsewhere.



Proposal D also includes a number of guidelines for proper behavior
around these emotionally charged issues.



The only difference between Proposal E and Proposal A is the severity of
the bug when non-systemd support is not in a package. In Proposal A,
this bug is important: potentially sufficient for a stable update, but
not release critical. As a practical matter, Proposal A allows the
non-systemd community to contribute (and NMU) patches for non-systemd
support. However, it does not place an obligation on maintainers to
write this support themselves. Proposal A would permit systemd
facilities like sysusers to be used, although doing so might be a bug.
In the specific case of sysusers, someone could justify NMUing a patch
to use adduser in a maintainer script. Unlike Proposal D, Proposal A
places the burden of keeping up with systemd facilities fully on the
non-systemd community. Proposal A does not have Proposal D's
requirement that it be reasonable to expect that the non-systemd
community can implement the facility.



Systemd Options

There are two systemd options: Proposal F
and Proposal
B
. Proposal F replaces a previous Proposal C. As far as I can tell
Proposal F and C do the same thing, but Proposal F has some text
describing principles. As I said in the introduction, I'm not
discussing that here.



Under Proposal F, systemd is the only officially supported option.
Other init systems may be explored at wishlist priority. Systemd
facilities such as sysusers are encouraged, and we will use our usual
mechanisms to plan transitions from Debian facilities where appropriate.



Proposal B does not explicitly say that alternate init system work can
only be wishlist. Under Proposal B, I think it would be reasonable to
file some bugs at normal severity, but it would also be reasonable for a
maintainer to downgrade them. I don't consider that a significant
difference.



The big difference is that Proposal B commits us as a project to
reviewing integrations of technologies that are alternatives to
systemd facilities. The current example is elogind. But things like
a non-systemd implementation of sysusers, tmpfiles.d, etc, would also
qualify. The rationale is that sometimes alternatives like that touch
on core infrastructure, and even if other maintainers are doing the
work, gatekeeper review is needed. Under Proposal B, the alternate technologies would be available, but whether to use them in a specific package would be up to the maintainer. I've discussed in another, more opinionated blog post why this might be a good idea.



Proposal G

As best I can tell Proposal G is just a set of principles. so, in the context of the analysis I have set out to perform here, I think there is nothing to say.

Thomas Goirand: Upgrading an OpenStack Rocky cluster from Stretch to Buster

Dje, 01/12/2019 - 5:45md

Upgrading an OpenStack cluster from one version of OpenStack to another has become easier, thanks to the versioning of objects in the rabbitmq message bus (if you want to know more, see what oslo.versionedobjects is). But upgrading from Stretch to Buster isn’t easy at all, event with the same version of OpenStack (it is easier to be running OpenStack Rocky backports on Stretch and upgrade to Rocky on Buster, rather than upgrading OpenStack at the same time as the system).

The reason it is difficult, is because rabbitmq and corosync in Stretch can’t talk to the versions shipped in Buster. Also, in a normal OpenStack cluster deployment, services on all machines are constantly doing queries to the OpenStack API, and exchanging messages through the RabbitMQ message bus. One of the dangers, for example, would be if a Neutron DHCP agent could not exchange messages with the neutron-rpc-server. Your VM instances in the OpenStack cluster then could loose connectivity.

If a constantly online HA upgrade with no downtime isn’t possible, it is however possible to minimize down time to just a few seconds, if following a correct procedure. It took me more than 10 tries to be able to do everything in a smooth way, understanding and working around all the issues. 10 tries, means installing 10 times an OpenStack cluster in Stretch (which, even if fully automated, takes about 2 hours) and trying to upgrade it to Buster. All of this is very time consuming, and I haven’t seen any web site documenting this process.

This blog post intends to document such a process, to save the readers the pain of hours of experimentation.

Note that this blog post asserts you’re cluster has been deployed using OCI (see: https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer) however, it should also apply to any generic OpenStack installation, or even to any cluster running RabbitMQ and Corosync.

The root cause of the problem more in details: incompatible RabbitMQ and Corosync in Stretch and Buster

RabbitMQ in Stretch is version 3.6.6, and Buster has version 3.7.8. In theory, the documentation of RabbitMQ says it is possible to smoothly upgrade a cluster with these versions. However, in practice, the problem is the Erlang version rather than Rabbit itself: RabbitMQ in Buster will refuse to talk to a cluster running Stretch (the daemon will even refuse to start).

The same way, Corosync 3.0 in Buster will refuse to accept messages from Corosync 2.4 in Stretch.

Overview of the solution for RabbitMQ & Corosync

To minimize downtime, my method is to shutdown RabbitMQ on node 1, and let all daemons (re-)connect to node 2 and 3. Then we upgrade node 1 fully, and then restart Rabbit in there. Then we shutdown Rabbit on node 2 and 3, so that all daemons of the cluster reconnect to node 1. If done well, the only issue is if a message is still in the cluster of node 2 and 3 when daemons fail-over to node 1. In reality, this isn’t really a problem, unless there’s a lot of activity on the API of OpenStack. If this was the case (for example, if running a public cloud), then the advise would simply to firewall the OpenStack API for the short upgrade period (which shouldn’t last more than a few minutes).

Then we upgrade node 2 and 3 and make them join the newly created RabbitMQ cluster in node 1.

For Corosync, node 1 will not allow start the VIP resource before node 2 is upgraded and both nodes can talk to each other. So we just upgrade node 2, and turn off the VIP resource on node 3 immediately when it is up on node 1 and 2 (which happens during the upgrade of node 2).

The above should be enough reading for most readers. If you’re not that much into OpenStack, it’s ok to stop reading this post. For those who are move involved users of OpenStack on Debian deployed with OCI, let’s go more in details…

Before you start: upgrading OCI

In previous versions of OCI, the haproxy configuration was missing a “option httpcheck” for the MariaDB backend, and therefore, if a MySQL server on one node was going down, haproxy wouldn’t detect it, and the whole cluster could fail (re-)connecting to MySQL. As we’re going to bring some MySQL servers down, make sure the puppet-master is running with the latest version of puppet-module-oci, and that the changes have been applied in all OpenStack controller nodes.

Upgrading compute nodes

Before we upgrade the controllers, it’s best to start by compute nodes, which are the most easy to do. The easiest way is to live-migrate all VMs away from the machine before proceeding. First, we disable the node, so no new VM can be spawned on it:

openstack compute service set --disable z-compute-1.example.com nova-compute

Then we list all VMs on that compute node:

openstack server list –all-projects –host z-compute-1.example.com

Finally we migrate all VMs away:

openstack server migrate --live hostname-compute-3.infomaniak.ch --block-migration 8dac2f33-d4fd-4c11-b814-5f6959fe9aac

Now we can do the upgrade. First disable pupet, then tweak the sources.list, upgrade and reboot:

puppet agent --disable "Upgrading to buster"
apt-get remove python3-rgw python3-rbd python3-rados python3-cephfs librgw2 librbd1 librados2 libcephfs2
rm /etc/apt/sources.list.d/ceph.list
sed -i s/stretch/buster/g /etc/apt/sources.list
mv /etc/apt/sources.list.d/stretch-rocky.list /etc/apt/sources.list.d/buster-rocky.list
echo "deb http://stretch-rocky.debian.net/debian buster-rocky-proposed-updates main
deb-src http://stretch-rocky.debian.net/debian buster-rocky-proposed-updates main" >/etc/apt/sources.list/buster-rocky.list
apt-get update
apt-get dist-upgrade
reboot

Then we simply re-apply puppet:

puppet agent --enable ; puppet agent -t
apt-get purge linux-image-4.19.0-0.bpo.5-amd64 linux-image-4.9.0-9-amd64

Then we can re-enable the compute service:

openstack compute service set --enable z-compute-1.example.com nova-compute

Repeate the operation for all compute nodes, then we’re ready for the upgrade of controller nodes.

Removing Ceph dependencies from nodes

Most likely, if running with OpenStack Rocky on Stretch, you’d be running with upstream packages for Ceph Luminous. When upgrading to Buster, there’s no upstream repository anymore, and packages will use Ceph Luminous directly from Buster. Unfortunately, the packages from Buster are in a lower version than the packages from upstream. So before upgrading, we must remove all Ceph packages from upstream. This is what has been done just above for the compute nodes also. Upstream Ceph packages are easily identifiable, because upstream uses “bpo90” instead of what we do in Debian (ie: bpo9), so the operation can be:

apt-get remove $(dpkg -l | grep bpo90 | awk '{print $2}' | tr '\n' ' ')

This will remove python3-nova, which is fine as it is also running on the other 2 controllers. After switching the /etc/apt/sources.list to buster, Nova can be installed again.

In a normal setup by OCI, here’s the sequence of command that needs to be done:

rm /etc/apt/sources.list.d/ceph.list
sed -i s/stretch/buster/g /etc/apt/sources.list
mv /etc/apt/sources.list.d/stretch-rocky.list /etc/apt/sources.list.d/buster-rocky.list
echo "deb http://stretch-rocky.debian.net/debian buster-rocky-proposed-updates main
deb-src http://stretch-rocky.debian.net/debian buster-rocky-proposed-updates main" >/etc/apt/sources.list/buster-rocky.list
apt-get update
apt-get dist-upgrade
apt-get install nova-api nova-conductor nova-consoleauth nova-consoleproxy nova-placement-api nova-scheduler

You may notice that we’re replacing the Stretch Rocky backports repository by one for Buster. Indeed, even if all of Rocky is in Buster, there’s a few packages that are still pending for the review of the Debian stable release team before they can be uploaded to Buster, and we need the fixes for a smooth upgrade. See release team bugs #942201, #942102, #944594, #941901 and #939036 for more details.

Also, since we only did a “apt-get remove”, the Nova configuration in nova.conf must have stayed, and nova is already configured, so when we reinstall the services we removed when removing the Ceph dependencies, they will be ready to go.

Upgrading the MariaDB galera cluster

In an HA OpenStack cluster, typically, a Galera MariaDB cluster is used. That isn’t a problem when upgrading from Stretch to Buster, because the on-the-wire format stays the same. However, the xtrabackup library in Stretch is held by the MariaDB packages themselves, while in Buster, one must install the mariadb-backup. As a consequence, best is to simply turn off MariaDB in a node, do the Buster upgrade, install the mariadb-backup package, and restart MariaDB. To avoid that the MariaDB package attempts restarting the mysqld daemon, best is to mask the systemd unit:

systemctl stop mysql.service
systemctl disable mysql.service
systemctl mask mysql.service

Upgrading rabbitmq-server

Before doing anything, make sure all of your cluster is running with the python3-oslo.messaging version >= 8.1.4. Indeed, version 8.1.3 suffers from a bug where daemons would attempt reconnect constantly to the same server, instead of trying each of the servers described in the transport_url directive. Note that I’ve uploaded 8.1.4-1+deb10u1 to Buster, and that it is part of the 10.2 Buster point release. Though upgrading oslo.messaging will not restart daemons automatically: this must be done manually.

The strategy for RabbitMQ is to completely upgrade one node, start Rabbit on it, without any clustering, then shutdown the service on the other 2 node of the cluster. If this is performed fast enough, no message will be list in the message bus. However, there’s a few traps. Running “rabbitmqctl froget_cluster_node” only removes a node from the cluster for those who will still be running. It doesn’t remove the other nodes from the one which we want to upgrade. The way I’ve found to solve this is to simply remove the mnesia database of the first node, so that when it starts, RabbitMQ doesn’t attempt to cluster with the other 2 which are running a different version of Erlang. If it did, then it would just fail and refused to start.

However, there’s another issue to take care. When upgrading the 1st node to Buster, we removed Nova, because of the Ceph issue. Before we restart the RabbitMQ service on node 1, we need to install Nova, so that it will connect to either node 2 or 3. If we don’t do that, then Nova on node 1 may connect to the RabbitMQ service on node 1, which at this point, is a different RabbitMQ cluster than the one in node 2 and 3.

rabbitmqctl stop_app
systemctl stop rabbitmq-server.service
systemctl disable rabbitmq-server.service
systemctl mask rabbitmq-server.service
[ ... do the Buster upgrade fully ...]
[ ... reinstall Nova services we removed when removing Ceph ...]
rm -rf /var/lib/rabbitmq/mnesia
systemctl unmask rabbitmq-server.service
systemctl enable rabbitmq-server.service
systemctl start rabbitmq-server.service

At this point, since the node 1 RabbitMQ service was down, all daemons are connected to the RabbitMQ service on node 2 or 3. Removing the mnesia database removes all the credentials previously added to rabbitmq. If nothing is done, OpenStack daemons will not be able to connect to the RabbitMQ service on node 1. If like I do, one is using a config management system to populate the access rights, it’s rather easy: simply re-apply the puppet manifests, which will re-add the credentials. However, that isn’t enough: the RabbitMQ message queues are created when the OpenStack daemon starts. As I experienced, daemons will reconnect to the message bus, but will not recreate the queues unless daemons are restarted. Therefore, the sequence is as follow:

Do “rabbitmqctl start_app” on the first node. Add all credentials to it. If your cluster was setup with OCI and puppet, simply look at the output of “puppet agent -t –debug” to capture the list of commands to perform the credential setup.

Do a “rabbitmqctl stop_app” on both remaining nodes 2 and 3. At this point, all daemons will reconnect to the only remaining server. However, they wont be able to exchange messages, as the queues aren’t declared. This is when we must restart all daemons in one of the controllers. The whole operation normally doesn’t take more than a few seconds, which is how long your message bus wont be available. To make sure everything works, check the logs in /var/log/nova/nova-compute.log of one of your compute nodes to make sure Nova is able to report its configuration to the placement service.

Once all of this is done, there’s nothing to worry anymore about RabbitMQ, as all daemons of the cluster are connected to the service on node 1. However, one must make sure that, when upgrading node 2 and 3, they don’t reconnect to the message service on node 2 and 3. So best is to simply stop, disable and mask the service with systemd before continuing. Then, when restarting the Rabbit service on node 2 and 3, OCI’s shell script “oci-auto-join-rabbitmq-cluster” will make them join the new Rabbit cluster, and everything should be fine regarding the message bus.

Upgrading corosync

In an OpenStack cluster setup by OCI, 3 controllers are typically setup, serving the OpenStack API through a VIP (a Virtual IP). What we call a virtual IP is simply an IP address which is able to move from one node to another automatically depending on the cluster state. For example, with 3 nodes, if one goes down, one of the other 2 nodes will take over hosting the IP address which serves the OpenStack API. This is typically done with corosync/pacemaker, which is what OCI sets up.

The way to upgrade corosync is easier than the RabbitMQ case. The first node will refuse to start the corosync resource if it can’t talk to at least a 2nd node. Therefore, upgrading the first node is transparent until we touch the 2nd node: the openstack-api resource wont be started on the first node, so we can finish the upgrade in it safely (ie: take care of RabbitMQ as per above). The first thing to do is probably to move the resource to the 3rd node:

crm_resource --move --resource openstack-api-vip --node z-controller-3.example.com

Once the first node is completely upgraded, we upgrade the 2nd node. When it is up again, we can check the corosync status to make sure it is running on both node 1 and 2:

crm status

If we see the service is up on node 1 and 2, we must quickly shutdown the corosync resource on node 3:

crm resource stop openstack-api-vip

If that’s not done, then node 3 may also reclaim the VIP, and therefore, 2 nodes may it. If running with the VIP using L2 protocol, normally switches will connect only one of the machines declaring the VIP, so even if we don’t take care of it immediately, the upgrade should be smooth anyway. If, like I do in production, you’re running with BGP (OCI allows one to use BGP for the VIP, or simply use an IP on a normal L2 network), then the situation must be even better, as the peering router will continue to route to one of the controllers in the cluster. So no stress, this must be done, but no need to hurry as much as for the RabbitMQ service.

Finalizing the upgrade

Once node 1 and 2 are up, most of the work is done, and the 3rd node can be upgraded without any stress.

Recap of the procedure for controllers

  • Move all SNAT virtual routers running on node 1 to node 2 or 3 (note: this isn’t needed if the cluster has network nodes).
  • Disable puppet on node 1.
  • Remove all Ceph libraries from upstream on node 1, which also turn off some Nova services that runtime depend on them.
  • shutdown rabbitmq on node 1, including masking the service with systemd.
  • upgrade node 1 to Buster, fully. Then reboot it. This probably will trigger MySQL re-connections to node 2 or 3.
  • install mariadb-backup, start the mysql service, and make sure MariaDB is in sync with the other 2 nodes (check the log files).
  • reinstall missing Nova services on node 1.
  • remove the mnesia db on node 1.
  • start rabbitmq on node 1 (which now, isn’t part of the RabbitMQ cluster on node 2 and 3).
  • Disable puppet on node 2.
  • populate RabbitMQ access rights on node 1. This can be done by simply applying puppet, but may be dangerous if puppet restarts the OpenStack daemons (which therefore may connect to the RabbitMQ on node 1), so best is to just re-apply the grant access commands only.
  • shutdown rabbitmq on node 2 and 3 using “rabbitmqctl stop_app”.
  • quickly restart all daemons on one controller (for example the daemons on node 1) to declare message queues. Now all daemons must be reconnected and working with the RabbitMQ cluster on node 1 alone.
  • Re-enable puppet, and re-apply puppet on node 1.
  • Move all Neutron virtual routers from node 2 to node 1.
  • Make sure the RabbitMQ services are completely stopped on node 2 and 3 (mask the service with systemd).
  • upgrade node 2 to Buster (shutting down RabbitMQ completely, masking the service to avoid it restarts during upgrade, removing the mnesia db for RabbitMQ, and finally making it rejoin the newly node 1 single node cluster using oci-auto-join-rabbitmq-cluster: normally, puppet does that for us).
  • Reboot node 2.
  • When corosync on node 2 is up again, check corosync status to make sure we are clustering between node 1 and 2 (maybe the resource on node 1 needs to be started), and shutdown the corosync “openstack-api-vip” resource on node 3 to avoid the VIP to be declared on both nodes.
  • Re-enable puppet and run puppet agent -t on node 2.
  • Make node 2 rabbitmq-server has joined the new cluster declared on node 1 (do: rabbitmqctl cluster_status) so we have HA for Rabbit again.
  • Move all Neutron virtual routers of node 3 to node 1 or 2.
  • Upgrade node 3 fully, reboot it, and make sure Rabbit is connected to node 1 and 2, as well as corosync working too, then re-apply puppet again.

Note that we do need to re-apply puppet each time, because of some differences between Stretch and Buster. For example, Neutron in Rocky isn’t able to use iptables-nft, and puppet needs to run some update-alternatives command to select iptables-legacy instead (I’m writing this because this isn’t obvious, it’s just that sometimes, Neutron fails to parse the output of iptables-nft…).

Last words as a conclusion

While OpenStack itself has made a lot of progress for the upgrade, it is very disappointing that those components on which OpenStack relies (like corosync, who is typically used as the provider of high availability), aren’t designed with backward compatibility in mind. It is also disappointing that the Erlang versions in Stretch and Buster are incompatible this way.

However, with the correct procedure, it’s still possible to keep services up and running, with a very small down time, even to the point that a public cloud user wouldn’t even notice it.

As the procedure isn’t easy, I strongly suggest anyone attempting such an upgrade to train before proceeding. With OCI, it is easy to do run a PoC using the openstack-cluster-installer-poc package, which is the perfect environment to train on: it’s easy to reproduce, reinstall a cluster and restart the upgrade procedure.

Jonathan Carter: Free Software Activities (2019-11)

Dje, 01/12/2019 - 1:14md

TL;DR: Mostly a bunch of package sponsoring this month. :)

2019-11-11: Sponsor package python-tempora (1.14.1-1) for Debian unstable (Python team request).

2019-11-11: Sponsor package python-jaraco.functools (2.0-2) for Debian unstable (Python team request).

2019-11-11: Review package fpylll (Needs some more work) (Python team request).

2019-11-12: Sponsor package fpylll (0.4.1+ds1-7) for Debian unstable (Python team request).

2019-11-12: Review package python-flask-openid (Needs some more work) (Python team request).

2019-11-12: Upload package calamares (3.2.16-1) to Debian unstable.

2019-11-12: Review package python-six (Deferred to maintainer) (Python team request).

2019-11-12: Upload package gnome-shell-extension-draw-on-your-screen (14.1-1) to Debian unstable.

2019-11-12: Upload package vim-airline (11-1) to Debian unstable.

2019-11-12: Upload package gnome-shell-extension-arc-menu (38-dev-3) to Debian unstable.

2019-11-12: Sponsor package python-opentimestamps (0.4.1-1) for Debian unstable (Python team request).

2019-11-12: Sponsor package sphinx-autodoc-typehints (1.9.0-1) for Debian unstable (Python team request).

2019-11-12: Sponsor package flask-principal (0.4.0-2) for Debian unstable (Python team request).

2019-11-13: Sponsor package runescape (0.6-2) for Debian unstable (mentors.debian.net request).

2019-11-13: Sponsor package trace-cmd (2.8.3-1) for Debian unstable (mentors.debian.net request).

2019-11-13: Sponsor package gexiv (0.12.0-1) for Debian unstable (mentors.debian.net request).

2019-11-13: Sponsor package notepadqq (2.0.0~beta1-1) for Debian unstable (mentors.debian.net request).

2019-11-13: Sponsor package hijra (0.4.1-2) for Debian unstable (mentors.debian.net request).

2019-11-13: Sponsor package simple-scan (3.34.1-2) for Debian unstable (mentors.debian.net request).

2019-11-13: Sponsor package gyros (0.3.12) for Debian unstable (mentors.debian.net request).

2019-11-13: Sponsor package sysbench (1.0.18+ds-1) for Debian unstable (mentors.debian.net request).

2019-11-14: Sponsor package onedrivesdk (1.1.8-2) for Debian unstable (Python team request).

2019-11-14: Sponsor package pympler (0.7+dfsg1-1) for Debian unstable (Python team request).

2019-11-14: Sponsor package python3-portend (2.5-1) for Debian unstable (Python team request).

2019-11-14: Sponsor package clamfs (1.1.0-1) for Debian unstable (mentors.debian.net request).

2019-11-14: Sponsor package xautolock (2.2-6) for Debian unstable (mentors.debian.net request).

2019-11-14: Review package piper (0.3-1) (Needs some more work) (mentors.debian.net request).

2019-11-14: Review package srcpy (1.10+ds-1) (Needs some more work) (mentors.debian.net request).

2019-11-14: Sponsor package python-ebooklib (0.17-1) for Debian unstable (mentors.debian.net request).

2019-11-14: Sponsor package plowshare (2.1.7-4) for Debian unstable (mentors.debian.net request).

2019-11-14: Sponsor package py-libzfs (0.0+git20191113.2991805-1) for Debian unstable (Python team request).

2019-11-18: Sponsor package rpl (1.6.3-1) for Debian unstable (mentors.debian.net request).

2019-11-19: Upload new package feed2toot (0.12-1) to Debian unstable.

2019-11-21: Sponsor package isbg (2.2.1-2) for Debian unstable (Python team request).

2019-11-21: Sponsor package python-elasticsearch (7.1.0-1) for Debian unstable (Python team request).

2019-11-21: Review package python-fsspec (0.6.0-1) (Needs some more work) (Python team request).

2019-11-21: Sponsor package blastem (0.6.3.3-2) for Debian unstable (mentors.debian.net request).

2019-11-21: Review package ledmon (0.93-1) for Debian unstable (needs some more work) (mentors.debian.net request).

2019-11-21: Sponsor package ripser (1.1-1) for Debian unstable (mentors.debian.net request).

2019-11-21: Sponsor package surgescript (0.5.4-1) for Debian unstable (mentors.debian.net request).

2019-11-21: Upload package power (1.4+dfsg-4) to Debian unstable (Closes: #854887).

2019-11-22: Sponsor package sqlobject (3.7.3+dfsg-1) for Debian unstable (Python team request).

2019-11-22: Upload package foliate (1.5.3+dfsg1-1) to Debian experimental.

2019-11-28: Sponsor package micropython (1.11-1) (E-mail request).

2019-11-28: Sponsor package qosmic (1.6.0-2) (mentors.debian.net request).

Junichi Uekawa: Feeling some Fate in Coincidence.

Dje, 01/12/2019 - 4:39pd
Feeling some Fate in Coincidence. Just by chance I saw some sign that impressed me and I feel something in the chance.

Paul Wise: FLOSS Activities November 2019

Dje, 01/12/2019 - 3:39pd
Changes Issues Review Administration
  • Chromium BSU: answer support requests
  • Funguloids: applied patches, ticket triage
  • Debian: updated apt repo key expiry
  • Debian website: fix directory permissions again
  • Debian wiki: diagnose DocBook output issue, unblacklist IP addresses, whitelist email addresses, whitelist email domains
Communication Sponsors

The purple-discord, libpst work was sponsored by my employer. All other work was done on a volunteer basis.

Keith Packard: picolibc-float

Dje, 01/12/2019 - 3:31pd
Picolibc Without Double

Smaller embedded processors may have no FPU, or may have an FPU that only supports single-precision mode. In either case, applications may well want to be able to avoid any double precision arithmetic as that will drag in a pile of software support code. Getting picolibc to cooperate so that it doesn't bring in double-precision code was today's exercise.

Take a look at the changes in git

__OBSOLETE_MATH is your friend

The newlib math library, which is where picolibc gets its math code, has two different versions of some functions:

  • single precision sin, cos and sincos
  • single and double precision exp, exp2 and log, log2 and pow

The older code, which was originally written at Sun Microsystems (most of this code carries a 1993 copyright), is quite careful to perform single precision functions using only single precision intermediate values.

The newer code, which carries a 2018 copyright from Arm Ltd, uses double precision intermediate values for single precision functions.

I haven't evaluated the accuracy of either algorithm, but the newer code claims to be faster on machines which support double in hardware.

However, for machines with no hardware double support, especially for machines with hardware single precision support, I'm betting the code which avoids double will be faster. Not to mention all of the extra space in ROM that would be used by a soft double implementation.

I had switched the library to always use the newer code while messing about with some really stale math code last month, not realizing exactly what this flag was doing. I got a comment on that patch from github user 'innerand' which made me realize my mistake.

I've switched the default back to using the old math code on platforms that don't have hardware double support, and using the new math code on platforms that do. I also added a new build option, -Dnewlib-obsolete-math, which can be set to auto, true, or false. auto mode is the default, which selects as above.

Float vs Double error handling

Part of the integration of the Arm math code changed how newlib/picolibc handles math errors. The new method calls functions to set errno and return a specific value back to the application, like __math_uflow, which calls __math_xflow which calls __math_with_errno. All of these versions take double parameters and return double results. Some of them do minor arithmetic on these parameters. There are also float versions of these handlers, which are for use in float operations.

One float function, the __OBSOLETE_MATH version of log1pf, was mistakenly using the double error handlers, __math_divzero and __math_invalid. Just that one bug pulled in most of the soft double precision implementation. I fixed that in picolibc and sent a patch upstream to newlib.

Float printf vs C ABI

The C ABI specifies that float parameters to varargs functions are always promoted to doubles. That means that printf never gets floats, only doubles. Program using printf will end up using doubles, even if there are no double values anywhere in the code.

There's no easy way around this issue — it's hard-wired in the C ABI. Smaller processors, like the 8-bit AVR, “solve” this by simply using the same 32-bit representation for both double and float. On RISC-V and ARM processors, that's not a viable solution as they have a well defined 64-bit double type, and both GCC and picolibc need to support that for applications requiring the wider precision.

I came up with a kludge which seems to work. Instead of passing a float parameter to printf, you can pass a uint32_t containing the same bits, which printf can unpack back into a float. Of course, both the caller and callee will need to agree on this convention.

Using the same mechanism as was used to offer printf/scanf functions without floating point support, when the #define value, PICOLIBC_FLOAT_PRINTF_SCANF is set before including stdio.h, the printf functions are all redefined to reference versions with this magic kludge enabled, and the scanf functions redefined to refer to ones with the 'double' code disabled.

A new macro, printf_float(x) can be used to pass floats to any of the printf functions. This also works in the normal version of the code, so you can use it even if you might be calling one of the regular printf functions.

Here's an example:

#define PICOLIBC_FLOAT_PRINTF_SCANF #include <stdio.h> #include <stdlib.h> int main(void) { printf("pi is %g\n", printf_float(3.141592f)); } Results

Just switching to float-only printf removes the following soft double routines:

  • __adddf3
  • __aeabi_cdcmpeq
  • __aeabi_cdcmple
  • __aeabi_cdrcmple
  • __aeabi_d2uiz
  • __aeabi_d2ulz
  • __aeabi_dadd
  • __aeabi_dcmpeq
  • __aeabi_dcmpge
  • __aeabi_dcmpgt
  • __aeabi_dcmple
  • __aeabi_dcmplt
  • __aeabi_dcmpun
  • __aeabi_ddiv
  • __aeabi_dmul
  • __aeabi_drsub
  • __aeabi_dsub
  • __aeabi_f2d
  • __aeabi_i2d
  • __aeabi_l2d
  • __aeabi_ui2d
  • __aeabi_ul2d
  • __cmpdf2
  • __divdf3
  • __eqdf2
  • __extendsfdf2
  • __fixunsdfdi
  • __fixunsdfsi
  • __floatdidf
  • __floatsidf
  • __floatundidf
  • __floatunsidf
  • __gedf2
  • __gtdf2
  • __ledf2
  • __ltdf2
  • __muldf3
  • __nedf2
  • __subdf3
  • __unorddf2

The program shrank by 2672 bytes:

$ size double.elf float.elf text data bss dec hex filename 48568 116 37952 86636 1526c double.elf 45896 116 37952 83964 147fc float.elf

Utkarsh Gupta: Debian Activities for November 2019

Dje, 01/12/2019 - 1:05pd

Here’s my (second) monthly update about the activities I’ve done in Debian this November.

Debian LTS

This was my second month as a Debian LTS paid contributor.
I was assigned 18 hours and worked on the following things:

CVE Fixes and Announcements:
  • Issued DLA 1984-1, fixing CVE-2019-17545, for gdal.
    Details here:

    GDAL through 3.0.1 had a poolDestroy double free in OGRExpatRealloc in ogr/ogr_expat.cpp when the 10MB threshold was exceeded.

    For Debian 8 “Jessie”, this has been fixed in 1.10.1+dfsg-8+deb8u1.
    Furthermore, sent a patch to the Security team for fixing the same in Stretch. Relevant .dsc can be found here. Since I haven’t heard back from the team yet, the upload to Stretch is still pending.

  • Issued DLA 1986-1, fixing CVE-2012017-1002201, for ruby-haml.
    Details here:

    In haml, when using user input to perform tasks on the server, characters like < > “ ‘ must be escaped properly. In this case, the ‘ character was missed. An attacker can manipulate the input to introduce additional attributes, potentially executing code.

    For Debian 8 “Jessie”, this has been fixed in 4.0.5-2+deb8u1.

  • Issued DLA 2004-1, fixing CVE-2019-14824, for 389-ds-base.
    Details here:

    A flaw was found in the ‘deref’ plugin of 389-ds-base where it could use the ‘search’ permission to display attribute values. In some configurations, this could allow an authenticated attacker to view private attributes, such as password hashes.

    For Debian 8 “Jessie”, this has been fixed in 1.3.3.5-4+deb8u7.
    Furthermore, sent a patch to the maintainer, Timo, for fixing the same in Bullseye, Sid. And to the Security team for Stretch and Buster. The patch can be found here.

  • Issued DLA 2005-1, fixing CVE-2019-18849, for tnef.
    Details here:

    In tnef, an attacker may be able to write to the victim’s .ssh/authorized_keys file via an e-mail message with a crafted winmail.dat application/ms-tnef attachment, because of a heap-based buffer over-read involving strdup.

    For Debian 8 “Jessie”, this has been fixed in 1.4.9-1+deb8u4.
    Furthermore, sent a patch to the maintainer for fixing the same in Bullseye, Sid. And to the Security team for Stretch and Buster. The patch can be found here.

Miscellaneous:
  • Fixed CVE-2019-11027 for ruby-openid in unstable. News here. This is in reference with the DLA 1956-1, issued by Brian May.

  • Triage libexif, libjpeg-turbo, tnef, and ansible for Jessie.

  • Pinged upstream of libexif and 389-ds-base for relevant commits. Whilst 389-ds-base is now fixed, the maintainer of libexif is still working on the fix.

  • In midst of fixing CVE-2019-18978 for ruby-rack-cors and CVE-2019-2201 for libjpeg-turbo.

Debian Uploads New Version:
  • ruby-openid ~ 2.9.2debian-1 (to unstable).
  • gitlab ~ 12.2.9-2 (to experimental).
  • node-yarnpkg ~ 1.19.1-1~bpo10+1 (to backports).
  • node-js-yaml ~ 3.13.1+dfsg-2~bpo10+1 (to backports).
  • ruby-sshkey ~ 2.0.0-2~bpo10+1 (to backports).
  • ruby-bootstrap-form ~ 4.2.0-2~bpo10+1 (to backports).
Bug Fixes:
  • #944906 for gitlab.
  • #930388 for ruby-openid.
  • #945232 for ruby-benchmark-suite.
Reviews and Sponsored Uploads:
  • node-hawk ~ 7.1.2+dfsg-1 for Sakshi Sangwan.
  • node-loud-rejection ~ 2.2.0-1 for Sakshi Sangwan.
  • node-lazy-cache ~ 2.0.2-1 for Sakshi Sangwan.

Until next time.
:wq for today.

Sam Hartman: The Case for Proposal B

Sht, 30/11/2019 - 9:36md

This is my personal opinion, not that of the project leader. Tomorrow,
I'll write an essay trying to discuss the various options in with as
little bias as I can manage (although even that will be Sam's opinion).
Several people have asked me why I included Proposal B.
This is my answer.


While I was talking to people about systemd and init systems, people
seemed to inherently assume that being uncomfortable with systemd meant
that you were in favor of sysvinit, or at least init-script based
solutions. At least, people who were heavily involved in the issue made
that assumption. That didn't resonate with me.


Several concerns commonly raised with systemd resonate with me:


  1. It combines a bunch of things in one project; as an example how you
    start daemons ends up being tied to how you configure the network.

  2. This combination seems like it might reduce innovation at least
    outside of the systemd ecosystem, because interfaces are coupled.

  3. It is Linux specific


Of these, the biggest concern for me is the idea that systemd might
stifle innovation by becoming one point of control.


And yet, in my opinion, systemd is vastly superior to the current
alternatives. I'd far rather be writing service units than init
scripts. They are more declarative. Dependencies that I care about are
easier to express. There are better security isolation facilities. In
non-Debian work I've found that I depend heavily on systemd because it
is easier and more pleasurable to code to than the alternatives.
Declarative syntax for managing users is useful. I haven't personally
seen the huge joy of socket activation, but if I were writing somewhat
different things, perhaps I would. Given
the options today, I would pick systemd hands down and not look back.


But what about tomorrow? For me, one of the great things about Debian
has been that it's possible to integrate new technologies and to try
things out. Debian has been the OS where I and many others could try
out new technologies and figure out what it was like to fully integrate
them into the operating system. Systemd is the best we've got now, but
I'm reluctant to step away from Debian as a platform for innovation and
experimentation.


Yet I don't think focusing on sysvinit or other init-script based
solutions actually has anything to do with the kind of innovation I'm
talking about. I understand that for people who value sysvinit (or
something like runit) above systemd, that work is valuable. My
experience is that for my needs, systemd is a better fit. I wanted a
proposal that allowed us to maintain Debian as a platform for innovation
without focusing on the legacy of init scripts. I think that if there
is going to be something that some day replaces systemd, it will support
service units (or a significant subset) not init scripts. I suspect it
will have a way to handle socket activation and so on. And I cannot
imagine a future systemd replacement that does not have advanced
security isolation features.


How it Works

Proposal B is a systemd focused proposal. It's very similar to Proposal F.
The text is different, but the implications of both proposals are
similar. Maintainers can use whatever systemd facilities they choose.
Init scripts are not required. For most maintainers, even thinking
about alternate init systems or future experiments is something entirely
optional. That's true under both proposal F and Proposal B.


Where they differ is in how much support the project gives to
experiments involving alternate init systems. Under Proposal F, that's
entirely optional at each member's discretion. My experience is that's
not sufficient for Debian to remain a community for innovation. My
experience is that key maintainers and teams maintaining central
infrastructure or packages often need to work with people who are trying
to integrate new features. The difference between Proposal B and F is
that under Proposal B, we commit to making that happen for technologies
that are important in exploring alternatives to systemd.


Obviously, no member of our community is obligated to do work. In
practice this commitment might mean working to find new volunteers to
help out key packages or teams and do this work. Sadly, there are areas
where the history of interaction has not been so good; behavior on
multiple sides of discussions has not lived up to our standards. In
addition to making sure we have the necessary volunteers for key
packages and teams,
part of meeting this commitment may involve working with people who
want to explore alternatives to systemd to find advocates who foster a
climate where we can be excellent to each other.


The Risks

There are some real risks with Proposal B. The biggest is that we'll
spend time working on integrations and nothing innovative will come out
of it. A possible outcome is that we spend a lot of time integrating
elogind and similar technologies, but they end up not being useful
because packages start depending on service units and socket
activations. Unless something new comes along, we may waste our
effort. Yet we've often been willing to spend effort to enable people
to try things. For me, this proposal is about reaffirming that aspect
of Debian.


In the worst case, it's possible that we decrease the quality of our
systemd integration leaving room for something else, spend significant
emotional energy, and do not end up with interesting innovation.
I think it's much more likely that if there is no interesting
innovation, Proposal B will slowly morph into Proposal F.


Why did You Do this?

In the beginning of this post, I talked about how I personally
considered the concerns about systemd separate than the desire to keep
init-script based systems running. That view is uncommon among people
who have been spending a lot of time on this issue. In general people
who are spending a lot of time on init systems seem to be fairly
divided. If you are trying to get work done today, you are probably
either fully using systemd or using one of the existing init-script
based alternatives.


However, my concern resonated with developers I talk to who spend less
time involved in the issue. Not people who were going to go research
things enough to write a proposal. But people who weren't sure that
systemd was the way and the light of the future, but found it had a lot
of great things going for it.


I was one of the few people who was taking the time to really understand
the issues but who was somewhat flexible. I didn't even know how I was
going to rank the options on my ballot until this morning. Yes, I've
been systemd leaning in some ways, but I also very much see the
arguments in favor of enabling people to keep other init systems
working. I'd be happy with most of the options on this ballot winning.
So, I tried to listen and see if there were ways of splitting
disagreement that wouldn't work for the people most committed to one
position, but might appeal to people who are less involved.


Why are you Writing This Post?

I think it's dangerous for someone who is project leader to speak a
personal opinion, especially on a controversial issue. However, I've
heard people struggling with some of the issues I discuss here in our
community. What I say may give people another way of looking at
things. I do think I have a valuable prospective because I have spent a
lot of time thinking about the issues but have not been as intimately
involved as others who have spent similar time. I think my need to act
as a facilitator at least for this GR is over. And after spending a day
considering, I think it's more beneficial to specifically ask the
project to think about Debian as a community for experimentation than to
say nothing.

Sylvain Beucler: Debian LTS and ELTS - November 2019

Sht, 30/11/2019 - 8:59md

Here is my transparent report for my work on the Debian Long Term Support (LTS) and Debian Extended Long Term Support (ELTS), which extend the security support for past Debian releases, as a paid contributor.

In November, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 24.5h for LTS (out of 30 max) and 20h for ELTS (max).

Multiple vulnerabilities come from in-process fuzzing (library fuzzing with compiler instrumentation, as opposed to fuzzing a user executable). This is an interesting technique, though those are harder to reproduce, especially with older versions or (even worse) forks. A significant portion of such vulnerabilities comes from google's OSS-117Fuzz infrastructure.

data/CVE/list from the debian security-tracker repository reached 20M. With multiple changes per hour, git blame is consequently near-unusable: several minutes for a targetted, single-line look-up, if the entry is not too old. Despite this, the git commit messages are often used for triage justification or even as a substitute for personal communication, a practice I wouldn't recommend. #908678 looks stalled.

MITRE is still reactive when reporting issues on various free software project, and still very shy about changing the status of vulnerabilities. This is understandable when dealing with hard-to-reproduce issues, less understandable with legit-looking bogus vulnerabilities, which some people still like to throw at us so we have more work to do and get paid (seriously: please don't).

ELTS - Wheezy

  • Second part of my Front-Desk week, though only auto-triaged unsupported packages
  • CVE-2019-14866/cpio: help opal investigate reproducibility issue, contact cpio maintainer and security@gnu.org to get official patch/review
  • CVE-2019-18684/sudo: deconstruct bogus vulnerability; MITRE now marks it as DISPUTED
  • CVE-2019-5068/mesa: attempt to reproduce the issue, BTS update, testing, security upload
  • CVE-2019-3466/postgresql-common: triage: not-affected
  • libonig: start work on multiple vulnerabilities with non-trivial backports; to be completed in December
  • CVE-2019-19012/libonig: backport for 5.9, get maintainer review
  • CVE-2019-19246/libonig: register CVE for untracked vulnerability (discovered through upstream fuzzing, re-discovered through php-mbstring)
  • libonig: find embedded copy in php7.0 (Stretch) and php7.3 (Buster); LTS/ELTS not-affected

LTS - Jessie

  • CVE-2019-3689/nfs-util: ping upstream and debian sid, no pong
  • CVE-2019-14866/cpio: shared work with ELTS
  • CVE-2019-18684/sudo: shared work with ELTS
  • CVE-2019-5068/mesa: shared work with ELTS, security upload
  • CVE-2019-3466/postgresql-common: confirmed fix: jessie already fixed but I didn't notice due to late DLA
  • CVE-2019-11027/ruby-openid: provide requested second opinion
  • libav: start processing pending issues, package is a ffmpeg fork, was removed from newer dists and is unresponsive to security issues, requiring more work; to be completed in December
  • CVE-2019-17542/libav: heap-based buffer overflow: apply fix though libfuzzer-based reproducer not reproducible
  • CVE-2019-17539/libav: triage: not-affected (vulnerable code introduced later)
  • CVE-2019-14443/libav: reproduce, track down fix in ffmpeg, update libav bug
  • CVE-2019-14441/libav: mitre request: duplicate CVE-2018-19129 (got DISPUTED); fix attempt, update libav bug
  • CVE-2019-14371/libav: triage: already fixed through CVE-2018-11102
  • CVE-2019-9720/libav: triage: unimportant (stretching the definition of DoS)
  • CVE-2019-9719/libav: mitre request: rejection (got DISPUTED): generic warning, no vulnerability
  • CVE-2019-9717/libav: triage: unimportant (stretching the definition of DoS)
  • CVE-2018-20001/libav: jessie triage: postponed (not reproducible)
  • CVE-2018-19130/libav: mitre request: duplicate CVE-2017-17127 (got DISPUTED)
  • CVE-2018-19128/libav: reproduce, track down fix in ffmpeg
  • Welcome new trainee

Documentation/Scripts

Sylvain Beucler: Debian LTS and ELTS - November 2019

Sht, 30/11/2019 - 8:25md

Here is my transparent report for my work on the Debian Long Term Support (LTS) and Debian Extended Long Term Support (ELTS), which extend the security support for past Debian releases, as a paid contributor.

In November, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 24.5h for LTS (out of 30 max) and 20h for ELTS (max).

Multiple vulnerabilities come from in-process fuzzing (library fuzzing with compiler instrumentation, as opposed to fuzzing a user executable). This is an interesting technique, though those are harder to reproduce, especially with older versions or (even worse) forks. A significant portion of such vulnerabilities comes from google's OSS-117Fuzz infrastructure.

data/CVE/list from the debian security-tracker repository reached 20M. With multiple changes per hour, git blame is consequently near-unusable: several minutes for a targetted, single-line look-up, if the entry is not too old. Despite this, the git commit messages are often used for triage justification or even as a substitute for personal communication, a practice I wouldn't recommend. #908678 looks stalled.

MITRE is still reactive when reporting issues on various free software project, and still very shy about changing the status of vulnerabilities. This is understandable when dealing with hard-to-reproduce issues, less understandable with legit-looking bogus vulnerabilities, which some people still like to throw at us so we have more work to do and get paid (seriously: please don't).

ELTS - Wheezy

  • Second part of my Front-Desk week, though only auto-triaged unsupported packages
  • CVE-2019-14866/cpio: help opal investigate reproducibility issue, contact cpio maintainer and security@gnu.org to get official patch/review
  • CVE-2019-18684/sudo: deconstruct bogus vulnerability; MITRE now marks it as DISPUTED
  • CVE-2019-5068/mesa: attempt to reproduce the issue, BTS update, testing, security upload
  • CVE-2019-3466/postgresql-common: triage: not-affected
  • libonig: start work on multiple vulnerabilities with non-trivial backports; to be completed in December
  • CVE-2019-19012/libonig: backport for 5.9, get maintainer review
  • CVE-2019-19246/libonig: register CVE for untracked vulnerability (discovered through upstream fuzzing, re-discovered through php-mbstring)
  • libonig: find embedded copy in php7.0 (Stretch) and php7.3 (Buster); LTS/ELTS not-affected

LTS - Jessie

  • CVE-2019-3689/nfs-util: ping upstream and debian sid, no pong
  • CVE-2019-14866/cpio: shared work with ELTS
  • CVE-2019-18684/sudo: shared work with ELTS
  • CVE-2019-5068/mesa: shared work with ELTS, security upload
  • CVE-2019-3466/postgresql-common: confirmed fix: jessie already fixed but I didn't notice due to late DLA
  • CVE-2019-11027/ruby-openid: provide requested second opinion
  • libav: start processing pending issues, package is a ffmpeg fork, was removed from newer dists and is unresponsive to security issues, requiring more work; to be completed in December
  • CVE-2019-17542/libav: heap-based buffer overflow: apply fix though libfuzzer-based reproducer not reproducible
  • CVE-2019-17539/libav: triage: not-affected (vulnerable code introduced later)
  • CVE-2019-14443/libav: reproduce, track down fix in ffmpeg, update libav bug
  • CVE-2019-14441/libav: mitre request: duplicate CVE-2018-19129 (got DISPUTED); fix attempt, update libav bug
  • CVE-2019-14371/libav: triage: already fixed through CVE-2018-11102
  • CVE-2019-9720/libav: triage: unimportant (stretching the definition of DoS)
  • CVE-2019-9719/libav: mitre request: rejection (got DISPUTED): generic warning, no vulnerability
  • CVE-2019-9717/libav: triage: unimportant (stretching the definition of DoS)
  • CVE-2018-20001/libav: jessie triage: postponed (not reproducible)
  • CVE-2018-19130/libav: mitre request: duplicate CVE-2017-17127 (got DISPUTED)
  • CVE-2018-19128/libav: reproduce, track down fix in ffmpeg
  • Welcome new trainee

Documentation/Scripts

Steinar H. Gunderson: More about the DDR arcade CDs

Sht, 30/11/2019 - 7:41md

I'm continuing my journey throughout the world of the Dance Dance Revolution arcade CDs; it would be interesting to see how moddable they are, even though I don't have a machine myself (obviously, MAME is absolutely essential here).

One key fact that I didn't know about last time, but was eventually alerted to after looking at others' work, is that the software in flash runs off of a virtual filesystem (VFS). This makes things incredibly much easier than mucking around with offsets everywhere. It's sort of a strange hybrid, though; read on for more.

The System 573 mainboard has 16 MB (or 128 Mbit, if you wish) of onboard flash, spread over a few banks, and for the newer digital mixes, this is augmented with a 32 MB PCMCIA flash card (I believe the system can technically address 64 MB, but no software uses it, to the best of my knowledge). When installing the software from CD-ROM, it blits a file called GAME.DAT into the onboard flash and CARD.DAT into the PCMCIA card (plus sets up some checksums at 0xfe0000). Except for a few hard-coded items, they seem to largely be treated equivalently, simply as different backing stores for a single VFS.

When booting up regularly (SW4 set to booting from flash), it jumps to an address very early in the flash, which contains the bootloader (called boot/psx.bin in the VFS; but the VFS has a too short size for it, so if you trust the size when extracting it, it gets too short!). The bootloader reads the (encrypted) configuration file from 0xFE2000 (addressed as “/.raw=0x1fc4,0x2000” in the VFS, probably partially related ot that the flash is mapped up at 0x1f000000), which contains information about how to address the two flash devices and a bit more. It also reads the file table for the VFS at 0xFE4000, and from there, it's mostly filesystem time: The bootloader then loads the game itself from soft/s573/aout.exe and boots it.

Everything in the VFS is addressed by CRC32 only (a Konami-specific variant that uses only six bits per input character). Besides the CRC32 field, offset and size, there are a few curious fields: In particular, there's an encryption bit that specifies that the file is encrypted using a home-grown very simple stream cipher (using the CRC32 of the string “EXTREME” as key…); it's more like obfuscation. Only a few very central files, like the song index, are encrypted—and nothing must be, except for the configuration file (which doesn't have the encryption bit set!).

Furthermore, files can be marked as compressed, using a Konami-specific LZ77 algorithm. Curiously enough, even though loading appears to be fairly generic, some files that are eminently compressable, such as some textures on the PCMCIA card, cannot be compressed, or the game will crash. But many of the textures are indeed compressed, and without it, there probably wouldn't be space on the flash. There's generally lots of space on the PCMCIA card, though.

So, given all of this knowledge, can we use it for modding? Yes! There's a tool set called sys573tools, which, among others, can extract data from the file system. (It guesses file names based on known patterns and data found in other files, so that you don't only get a bunch of CRCs.) Given that, we can decrypt the music database, add more songs (for instance from other DDR mixes), pack everything back up again, flash, and then enjoy more songs. It's still pretty raw, but it seems to work pretty well.

How many songs is there room for? Nobody really knows. The machines can be fitted with with DVD drives, so there's plenty of CD space, but there's not infinite amount of RAM on the I/O board (which supposedly holds all the shorts, all the time), and nobody really knows what the limits of the internal structures are.

So, does anyone have a DWI-to-CSQ converter for neoMAX?

Chris Lamb: Free software activities in November 2019

Sht, 30/11/2019 - 3:55md

Software Freedom Conservancy, the fiscal sponsor for the Reproducible Builds project, have announced their fundraising season with a huge pledge to match donations. If you have been considering joining as a supporter, now would be the time to do so.


Here is my monthly update covering what I have been doing in the free software world during November 2019 (previous month):

  • As part of my duties of being on the board of directors of the Open Source Initiative I attended our autumn face-to-face meeting hosted by Zolando in Berlin, Germany. I also participated in various licensing and other discussions occurring on the internet, as well as the usual internal discussions regarding logistics, policy, etc. liasing at times with the ClearlyDefined project.

  • Started early conversations as the Head Judge for the next interation of the OpenUK awards to be given out in June 2020.

  • As part serving on board of the Software in the Public Interest, Inc. I attended my first face-to-face meeting in Manhattan, New York which was graciously hosted by Hudson River Trading. It was great to meet the rest of the board in person after talking at such length over the internet.

  • Opened pull requests to make the build reproducible in:


Reproducible builds

Whilst anyone can inspect the source code of free software for malicious flaws almost all software is distributed pre-compiled to end users.

The motivation behind the Reproducible Builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised.

The initiative is proud to be a member project of the Software Freedom Conservancy, a not-for-profit 501(c)(3) charity focused on ethical technology and user freedom.

Conservancy acts as a corporate umbrella, allowing projects to operate as non-profit initiatives without managing their own corporate structure. If you like the work of the Conservancy or the Reproducible Builds project, please consider becoming an official supporter.

Conservancy's fundraising season has begin in earnest with a huge pledge to match donations from a number of illustrious individuals. If you have ever considered joining as a supporter, now would be the time to do so.


This month, I:

  • I spent a few moments on our website this month too including dropping the duplicated use the term "community" and other words [...][...], correcting the capitalisation of GitHub & GitLab [...] and corrected the use of "an" [...].

  • Drafted, published and publicised our monthly report.

  • strip-nondeterminism is our tool to remove specific non-deterministic results from a completed build. This month, I added file as a dependency for libfile-stripnondeterminism-perl (#945212) and moved away from deprecated $ADTTMP variable [...].

  • Did some arrangement, organisation and financial administration regarding our upcoming summit meeting in Marrakesh, Morocco.

I also made the following changes to diffoscope, our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues:

  • New features / improvements:

    • Allow all possible .zip file variations to return from external tools with non-zero exit codes, not just known types we can identify (eg. Java .jmod and .jar files). (#78)
    • Limit .dsc and .buildinfo file matching to files in ASCII or UTF-8 format. (#77)
    • Bump the previous max_page_size limit from 400 kB to 4 MB. [...]
    • Clarify in the HTML and text outputs that the limits are per-format, not global. (#944882)
    • Don't use line-base dbuffering when communucating with subprocesses in "binary" mode. (#75)
  • Regression fixes:

    • Correct the substitution/filtering of paths in ELF output to avoid unnecessary differences depending on the path name provided and commandline. (#945572)
    • Silence/correct a Python SyntaxWarning message due to incorrectly comparing an integer by identity vs. equality. (#945531)
  • Testsuite improvements:

    • Refresh the OCaml test fixtures to support versions greater than 4.08.1. [...]
    • Update an Android manifest test to reflect that parsed XML attributes are returned in a new/sorted manner under Python 3.8. [...]
    • Dramatically Truncate the tcpdump expected diff to 8KB from ~600KB to reduce the size of the release tarball. [...]
    • Add a self-test to encourage that new test data files are generated dynamically or at least no new ones are added without an explicit override. [...]
    • Add a comment that the text_ascii1 and text_ascii2 fixture files are used in multiple tests so is not trivial to remove/replace them. [...]
    • Drop two more test fixture files for the directory tests. [...]
    • Don't run our self-test against the output of the Black source code reformatter with versions earlier than ours as it will generate different results. [...]
    • Update an XML test for Python 3.8. [...]
    • Drop unused an unused BASE_DIR global. [...]
  • Code improvements:

    • Rework a long string of or statements into a loop with a break. [...]
    • Update code to reflect the latest version of the Black source code reformatter. [...]
    • Correct a reference to the .rdx extension suffix in a comment. [...]


Debian

Uploads
  • redis (5:5.0.7-1) — New upstream release.

  • python-django (2.2.7-1 & 3.0~rc1-1) — New upstream releases.

  • cpio (2.13+dfsg-1) — New upstream release.

  • libfiu (1.00-4) — Prevent a build failure when multiple Python version libraries exist in the build tree by manually deleting all but the version for the default Python version returned by py3versions prior to running the test suite. (#944911)

  • gunicorn (20.0.0-1 & 20.0.2-1) — New upstream releases.

  • memcached (1.5.20-1) — New upstream release.

I also sponsored an upload of adminer (4.7.5-1) of behalf of Alexandre Rossi.


Debian bugs filed
  • RFP (Request for Package) for container-diff. (#945524)

  • bowtie2: imp Python module deprecation warning is embedded into bowtie2-inspect(1) manpage. (#945422)

  • golang-github-nrdcg-goinwx: Please update/expand the "Andrew" copyright holder. (#944066)

  • pcb-rnd: /usr/lib symlinks point to an (absolute) build directory. (#943955)

Debian LTS

This month I have worked 18 hours on Debian Long Term Support (LTS) and 12 hours on its sister Extended LTS project.

You can find out more about the project via the following video:


FTP Team

As a Debian FTP assistant I ACCEPTed 21 packages: golang-github-boj-redistore, golang-github-dchest-uniuri, golang-github-jackc-fake, golang-github-joyent-gocommon, golang-github-mattetti-filebuffer, golang-github-nrdcg-goinwx, golang-github-pearkes-dnsimple, golang-github-soniah-dnsmadeeasy, golang-github-vultr-govultr, golang-github-zorkian-go-datadog-api, meep, meep-mpi-default, meep-openmpi, node-eslint-plugin-requirejs, node-i18next, node-node-sass, node-re2, ocplib-endian, python-asynctest, python-janus & python-matrix-nio.