• Antoine Beaupr did 8h.
• Ben Hutchings did 12.75 hours (out of 11 hours allocated + 7.25 extra hours remaining, meaning that he still has 5.50 extra hours to do over April).
• Brian May did 10 hours.
• Chris Lamb did 7 hours (instead of the 14.25 hours he was allocated +, compensating the extra hours he did last month).
• Damyan Ivanov did nothing out of the 7.25 remaining hours he had, he opted to give them back and come back to LTS work later.
• Guido G nther did 13 hours (out of 12 hours allocated + 4.25 remaining hours, leaving 3.25 extra hours for April).
• Markus Koschany did 14.25 hours.
• Mike Gabriel did nothing and opted to give back the 8 hours allocated. He will stop LTS work for now as he has other projects taking all his time.
• Santiago Ruano Rinc n did 10 hours (out of 12h allocated + 1.50 remaining, thus keeping 3.50 extra hours for April).
• Scott Kitterman did a few hours but was not able to provide his report in time due to sickness. His next report will cover two months.
• Thorsten Alteholz did 14.25 hours.

• Platinum sponsors:
• TOSHIBA (for 6 months)
• Gold sponsors:
• The Positive Internet (for 22 months)
• Blablacar (for 21 months)
• Linode LLC (for 11 months)
• Silver sponsors:
• Domeneshop AS (for 21 months)
• Universit Lille 3 (for 21 months)
• Trollweb Solutions (for 19 months)
• Nantes M tropole (for 15 months)
• University of Luxembourg (for 13 months)
• Dalenys (for 11 months)
• Univention GmbH (for 7 months)
• Universit Jean Monnet de St Etienne (for 7 months)
• Sonus Networks
• Bronze sponsors:
• David Ayers IntarS Austria (for 22 months)
• Offensive Security (for 22 months)
• Seznam.cz, a.s. (for 22 months)
• Evolix (for 21 months)
• Freeside Internet Service (for 21 months)
• MyTux (for 21 months)
• Linuxhotel GmbH (for 19 months)
• Intevation GmbH (for 18 months)
• Daevel SARL (for 17 months)
• Bitfolk LTD (for 16 months)
• Megaspace Internet Services GmbH (for 16 months)
• Greenbone Networks GmbH (for 15 months)
• NUMLOG (for 15 months)
• WinGo AG (for 14 months)
• Ecole Centrale de Nantes LHEEA (for 11 months)
• Sig-I/O (for 8 months)
• Entr ouvert (for 6 months)
• Adfinis SyGroup AG (for 3 months)

No comment Liked this article? Click here. My blog is Flattr-enabled.

oldhost
newhost
[mygroup]
oldhost
# missing newhost here

$ ansible-playbook deploy-mygroup.yml --limit-hosts=newhost
<snip>
PLAY [deploy] *************************************************
skipping: no hosts matched
PLAY RECAP ****************************************************
[ERROR]: No plays were matched by any host.
$ echo $?
0

$ ansible-playbook [..] --error-if-no-plays-matched
<snip>
[ERROR]: No plays were matched by any host.
$ echo $?
1

publishers  
  textFinder(/^skipping: no hosts matched$/, '', true, false, false)
 

+ ansible-playbook deploy-mygroup.yml --limit-hosts=newhost
<snip>
PLAY [deploy] *************************************************
skipping: no hosts matched
PLAY RECAP ****************************************************
[ERROR]: No plays were matched by any host.
Checking console output
/var/lib/jenkins/jobs/deploy-mygroup/builds/126/log:
skipping: no hosts matched
Build step 'Jenkins Text Finder' changed build result to FAILURE
Finished: FAILURE

pytest in a nutshell pytest is a Python testing tool whose primary use is to write tests for Python applications but is versatile enough for other creative usages. It is bundled with three killer features:

• you can directly use the assert keyword,
• you can inject fixtures in any test function, and
• you can parametrize tests.

Assertions With unittest, the unit testing framework included with Python, and many similar frameworks, unit tests have to be encapsulated into a class and use the provided assertion methods. For example:

class testArithmetics(unittest.TestCase):
    def test_addition(self):
        self.assertEqual(1 + 3, 4)

The equivalent with pytest is simpler and more readable:

def test_addition():
    assert 1 + 3 == 4

pytest will analyze the AST and display useful error messages in case of failure. For further information, see Benjamin Peterson s article.

Fixtures A fixture is the set of actions performed in order to prepare the system to run some tests. With classic frameworks, you can only define one fixture for a set of tests:

class testInVM(unittest.TestCase):
    def setUp(self):
        self.vm = VM('Test-VM')
        self.vm.start()
        self.ssh = SSHClient()
        self.ssh.connect(self.vm.public_ip)
    def tearDown(self):
        self.ssh.close()
        self.vm.destroy()
    def test_hello(self):
        stdin, stdout, stderr = self.ssh.exec_command("echo hello")
        stdin.close()
        self.assertEqual(stderr.read(), b"")
        self.assertEqual(stdout.read(), b"hello\n")

In the example above, we want to test various commands on a remote VM. The fixture launches a new VM and configure an SSH connection. However, if the SSH connection cannot be established, the fixture will fail and the tearDown() method won t be invoked. The VM will be left running. Instead, with pytest, we could do this:

@pytest.yield_fixture
def vm():
    r = VM('Test-VM')
    r.start()
    yield r
    r.destroy()
@pytest.yield_fixture
def ssh(vm):
    ssh = SSHClient()
    ssh.connect(vm.public_ip)
    yield ssh
    ssh.close()
def test_hello(ssh):
    stdin, stdout, stderr = ssh.exec_command("echo hello")
    stdin.close()
    stderr.read() == b""
    stdout.read() == b"hello\n"

The first fixture will provide a freshly booted VM. The second one will setup an SSH connection to the VM provided as an argument. Fixtures are used through dependency injection: just give their names in the signature of the test functions and fixtures that need them. Each fixture only handle the lifetime of one entity. Whatever a dependent test function or fixture succeeds or fails, the VM will always be finally destroyed.

Parameters If you want to run the same test several times with a varying parameter, you can dynamically create test functions or use one test function with a loop. With pytest, you can parametrize test functions and fixtures:

@pytest.mark.parametrize("n1, n2, expected", [
    (1, 3, 4),
    (8, 20, 28),
    (-4, 0, -4)])
def test_addition(n1, n2, expected):
    assert n1 + n2 == expected

Testing lldpd The general plan for to test a feature in lldpd is the following:

1. Setup two namespaces.
2. Create a virtual link between them.
3. Spawn a lldpd process in each namespace.
4. Test the feature in one namespace.
5. Check with lldpcli we get the expected result in the other.

Here is a typical test using the most interesting features of pytest:

@pytest.mark.skipif('LLDP-MED' not in pytest.config.lldpd.features,
                    reason="LLDP-MED not supported")
@pytest.mark.parametrize("classe, expected", [
    (1, "Generic Endpoint (Class I)"),
    (2, "Media Endpoint (Class II)"),
    (3, "Communication Device Endpoint (Class III)"),
    (4, "Network Connectivity Device")])
def test_med_devicetype(lldpd, lldpcli, namespaces, links,
                        classe, expected):
    links(namespaces(1), namespaces(2))
    with namespaces(1):
        lldpd("-r")
    with namespaces(2):
        lldpd("-M", str(classe))
    with namespaces(1):
        out = lldpcli("-f", "keyvalue", "show", "neighbors", "details")
        assert out['lldp.eth0.lldp-med.device-type'] == expected

First, the test will be executed only if lldpd was compiled with LLDP-MED support. Second, the test is parametrized. We will execute four distinct tests, one for each role that lldpd should be able to take as an LLDP-MED-enabled endpoint. The signature of the test has four parameters that are not covered by the parametrize() decorator: lldpd, lldpcli, namespaces and links. They are fixtures. A lot of magic happen in those to keep the actual tests short:

• lldpd is a factory to spawn an instance of lldpd. When called, it will setup the current namespace (setting up the chroot, creating the user and group for privilege separation, replacing some files to be distribution-agnostic, ), then call lldpd with the additional parameters provided. The output is recorded and added to the test report in case of failure. The module also contains the creation of the pytest.config.lldpd object that is used to record the features supported by lldpd and skip non-matching tests. You can read fixtures/programs.py for more details.
• lldpcli is also a factory, but it spawns instances of lldpcli, the client to query lldpd. Moreover, it will parse the output in a dictionary to reduce boilerplate.
• namespaces is one of the most interesting pieces. It is a factory for Linux namespaces. It will spawn a new namespace or refer to an existing one. It is possible to switch from one namespace to another (with with) as they are contexts. Behind the scene, the factory maintains the appropriate file descriptors for each namespace and switch to them with setns(). Once the test is done, everything is wipped out as the file descriptors are garbage collected. You can read fixtures/namespaces.py for more details. It is quite reusable in other projects².
• links contains helpers to handle network interfaces: creation of virtual ethernet link between namespaces, creation of bridges, bonds and VLAN, etc. It relies on the pyroute2 module. You can read fixtures/network.py for more details.

You can see an example of a test run on the Travis build for 0.9.2. Since each test is correctly isolated, it s possible to run parallel tests with pytest -n 10 --boxed. To catch even more bugs, both the address sanitizer (ASAN) and the undefined behavior sanitizer (UBSAN) are enabled. In case of a problem, notably a memory leak, the faulty program will exit with a non-zero exit code and the associated test will fail.

---

1. A project like cwrap would definitely help. However, it lacks support for Netlink and raw sockets that are essential in lldpd operations.
2. There are three main limitations in the use of namespaces with this fixture. First, when creating a user namespace, only root is mapped to the current user. With lldpd, we have two users (root and _lldpd). Therefore, the tests have to run as root. The second limitation is with the PID namespace. It s not possible for a process to switch from one PID namespace to another. When you call setns() on a PID namespace, only children of the current process will be in the new PID namespace. The PID namespace is convenient to ensure everyone gets killed once the tests are terminated but you must keep in mind that /proc must be mounted in children only. The third limitation is that, for some namespaces (PID and user), all threads of a process must be part of the same namespace. Therefore, don t use threads in tests. Use multiprocessing module instead.

Debian SunCamp 2016 Hotel Anabel, LLoret de Mar, Province of Girona, Catalonia, Spain May 26-29, 2016

• Provide a functioning screen lock on systems using the X11 windowing system, a job made incredibly difficult due to a variety of design misfeatures in said windowing system[1]
• Provide cute graphical output while the screen is locked

• You can't directly modify the contents of the PCR. In order to obtain a specific value, you need to perform the same set of writes in the same order. If you replace the trusted bootloader with an untrusted one that runs arbitrary code, you can't rewrite the PCR to cover up that fact
• The PCR value is predictable and can be reconstructed by replaying the same series of operations

The paths of life to guide us towards the knowledge are many and a straight; well-defined line does not always represent them. Among these, the theory of Fuzzy Logic can help us to better understand some of the methods that maybe for too long we have lost the habit to use, if not even forgotten, because of the residuals of the positivist scientism.

Brief mathematical introduction

All the elements making up the majority of the categories of everyday life (feelings, emotions, opinions, values, quality, etc.) cannot be defined in a unique or exact way. Let s try to define an event that causes severe pain: a hammer blow on the finger? The loss of a loved one? Tooth extraction? It is evident that the answer can vary in a very consistent way, based on the subjectivity of the individual, the environment, boundary conditions and the general context. This is because the Strong Pain is a fuzzy set (which we will call SP), characterized by a function of degree of membership which maps the elements of a universe in a real continuous interval between 0 and 1. In practical terms

<Read More [by Fabio Marzocca]>

[user@mymachine ~]$ chromium-browser --proxy-auto-detect

1. Create /usr/local/share/applications/ unless it already exists
2. Copy /usr/share/applications/google-chrome.deskop to /usr/local/share/applications/.
3. Copy /usr/share/applications/chromium-browser.deskop to /usr/local/share/applications/.
4. Set the x-bit on those .desktop files: sudo chmod a+x /usr/local/share/applications/*.desktop
5. Edit both .desktop files and search for lines starting with Exec=. Add --proxy-auto-detect to each of those occurrences after the actual command (see diff below).
6. Run update-desktop-database /usr/local/share/applications

--- usr/share/applications/chromium-browser.desktop	2016-03-16 19:04:18.000000000 +0100
+++ usr/local/share/applications/chromium-browser.desktop	2016-04-01 14:23:27.410775206 +0200
@@ -167,7 +167,7 @@
 Comment[zh_CN]= 
 Comment[zh_HK]= 
 Comment[zh_TW]= 
-Exec=chromium-browser %U
+Exec=chromium-browser --proxy-auto-detect %U
 Terminal=false
 X-MultipleArgs=false
 Type=Application
@@ -216,7 +216,7 @@
 Name[vi]=M  c a s  m i
 Name[zh_CN]= 
 Name[zh_TW]= 
-Exec=chromium-browser
+Exec=chromium-browser --proxy-auto-detect
 
 [Desktop Action Incognito]
 Name=Open a New Window in incognito mode
@@ -254,7 +254,7 @@
 Name[vi]=M  c a s  m i trong ch     n danh
 Name[zh_CN]= 
 Name[zh_TW]= 
-Exec=chromium-browser --incognito
+Exec=chromium-browser --incognito --proxy-auto-detect
 
 [Desktop Action TempProfile]
 Name=Open a New Window with a temporary profile
@@ -292,4 +292,4 @@
 Name[vi]=M  c a s  m i v i h  s  t m
 Name[zh_CN]= 
 Name[zh_TW]= 
-Exec=chromium-browser --temp-profile
+Exec=chromium-browser --temp-profile --proxy-auto-detect

--- usr/share/applications/google-chrome.desktop	2016-04-01 14:02:29.388283436 +0200
+++ usr/local/share/applications/google-chrome.desktop	2016-04-01 14:13:59.381895899 +0200
@@ -105,7 +105,7 @@
 Comment[zh_CN]= 
 Comment[zh_HK]= 
 Comment[zh_TW]= 
-Exec=/usr/bin/google-chrome-stable %U
+Exec=/usr/bin/google-chrome-stable --proxy-auto-detect %U
 Terminal=false
 Icon=google-chrome
 Type=Application
@@ -165,7 +165,7 @@
 Name[vi]=C a s  M i
 Name[zh_CN]= 
 Name[zh_TW]= 
-Exec=/usr/bin/google-chrome-stable
+Exec=/usr/bin/google-chrome-stable --proxy-auto-detect
 TargetEnvironment=Unity
 
 [NewIncognito Shortcut Group]
@@ -218,5 +218,5 @@
 Name[vi]=C a s   n danh m i
 Name[zh_CN]= 
 Name[zh_TW]= 
-Exec=/usr/bin/google-chrome-stable --incognito
+Exec=/usr/bin/google-chrome-stable --proxy-auto-detect --incognito
 TargetEnvironment=Unity

Debian Long Term Support (LTS) This is my 4th month working on Debian LTS, started by Raphael Hertzog at Freexian. I spent half of the month away on a vacation so little work was done, especially since I tried to tackle rather large uploads like NSS and Xen. I also worked on the frontdesk shift last week.

Frontdesk That work mainly consisted of figuring out how to best help the security team with the last uploads to the Wheezy release. For those who don't know, Debian 7 Wheezy, or "oldstable", is going to be unsupported by the security team starting end of april, and the Debian 6 Squeeze (the previous LTS) is now unsupported. The PGP signatures on the archived release have started yielding expiration errors which can be ignored but that are really a strong reminder that it is really time to upgrade. So the LTS team is now working towards backporting a few security issues from squeeze to wheezy, and this is what I focused on during triage work. I have identified the following high priority packages I will work on after I complete my work on the Xen and NSS packages (detailed below):

• libidn
• icu
• phpmyadmin
• tomcat6
• optipng
• srtp
• dhcpcd
• python-tornado

Updates to NSS and Xen I have spent a lot of time testing and building packages for NSS and Xen. To be fair, Brian May did most of the work on the Xen packages, and I merely did some work to test the packages on Koumbit's infrastructure, something which I will continue doing in the next month. For NSS, wheezy and jessie are in this weird state where patches were provided to the security team all the way back in November yet were never tested. Since then, yet more issues came up and I worked hard to review and port patches for those new security issues to wheezy. I'll followup on both packages in the following month.

Other free software work

Android TL;DR: there's an even longer version of this with the step-by-step procedures and that I will update as time goes on in my wiki. I somehow inherited an Android phone recently, on a loan from a friend because the phone broke one too many times and she got a new one from her provider. This phone is a HTC One S "Ville", which is fairly old, but good enough to play with and give me a mobile computing platform to listen to podcasts, play music, access maps and create GPS traces. I was previously doing this with my N900, but that device is really showing its age: very little development is happening on it, the SDK is closed source and the device itself is fairly big, compared to the "Ville". Plus, the SIM card actually works on the Ville so, even though I do not have an actual contract with a cell phone provider (too expensive, too invasive on my privacy), I can still make emergency phone calls (911)! Plus, since there is good wifi on the machine, I can use it to connect to the phone system with the built-in SIP client, send text messages through SMS (thanks to VoIP.ms SMS support) or Jabber. I have also played around with LibreSignal, the free software replacement for Signal, which uses proprietary google services. Yes, the VoIP.ms SMS app also uses GCM, but hopefully that can be fixed. (While I was writing this, another Debian Developer wrote a good review of Signal so I am happy to skip that step. Go read that.)

See also my apps list for a more complete list of the apps I have installed on the phone. I welcome recommendations on cool free software apps I should use!

I have replaced the stock firmware on the phone with Cyanogenmod 12.1, which was a fairly painful experience, partly because of the difficult ambiance on the #cyanogenmod channel on Freenode, where I had extreme experiences: a brave soul helped me through the first flashing process for around 2 hours, nicely holding my hand at every step. Other times, I have seen flames and obtuse comments from people being vulgar, brutal, obnoxious, if not sometimes downright homophobic and sexist from other users. It is clearly a community that needs to fix their attitude. I have documented everything I could in details in this wiki page, in case others want to resuscitate their old phones, but also because I ended up reinstalling the freaking phone about 4 times, and was getting tired of forgetting how to do it every time. I am somewhat fascinated by Android: here is the Linux-based device that should save us all from the proprietary Apple nightmares of fenced in gardens and censorship. Yet, public Android downloads are hidden behind license agreements, even though the code itself is free, which has led fellow Debian developers to work on making libre rebuilds of Androids to workaround this insanity. But worse: all phones are basically proprietary devices down to the core. You need custom firmware to be loaded on the machine for it to boot at all, from the bootloader all the way down to the GSM baseband and Wifi drivers. It is a minefield of closed source software, and trying to run free software on there is a bit of a delusion, especially since the baseband has so much power over the phone. Still, I think it is really interesting to run free software on those machines, and help people that are stuck with cell phones get familiar with software freedom. It seems especially important to me to make Android developers aware of software freedom considering how many apps are available for free yet on which it is not possible to contribute significantly because the source code is not published at all, or published only on the Google Store, instead of the more open and public F-Droid repository which publishes only free software. So I did contribute. This month, I am happy to announce that I contributed to the following free software projects on Android:

• listmyapps: feature request, patch
• Locker: bug report, added to f-droid
• Sensorium: bug report
• LibreSignal: feature request and testing

I have also reviewed the literature surrounding Telegram, a popular messaging app rival to Signal and Whatsapp. Oddly enough, my contributions to Wikipedia on that subject were promptly reverted which made me bring up the subject on the page's Talk page. This lead to an interesting response from the article's main editors which at least added that the "its security features have been contested by security researchers and cryptography experts". Considering the history of Telegram, I would keep people away from it and direct people to use Signal instead, even though Signal has similar metadata issues, mostly because Telegram's lack of response to the security issues that were outlined by fellow security researchers. Both systems suffer from a lack of federation as well, which is a shame in this era of increasing centralization. I am not sure I will put much more work in developing for Android for now. It seems like a fairly hostile platform to work on, and unless I have specific pain points I want to fix, it feels so much better to work on my own stuff in Debian. Which brings me to my usual plethora of free software projects I got stuck in this month.

IRC projects irssi-plugin-otr had a bunch of idiotic bugs lying around, and I had a patch that I hadn't submitted upstream from the Debian package, which needed a rebuild because the irssi version changed, which is a major annoyance. The version in sid is now a snapshot because upstream needs to make a new release but at least it should fix things for my friends running unstable and testing. Hopefully those silly uploads won't be necessary in the future. That's for the client side. On the server side, I have worked on updating the Atheme-services package to the latest version, which actually failed because the upstream libmowgli is missing release tags, which means the Debian package for it is not up-to-date either. Still, it is nice to have a somewhat newer version, even though it is not the latest and some bugs were fixed. I have also looked at making atheme reproducible but was surprised at the hostility of the upstream. In the end, it looks like they are still interested in patches, but they will be a little harder to deploy than for Charybdis, so this could take some time. Hopefully I will find time in the coming weeks to test the new atheme services daemon on the IRC network I operate.

Syncthing I have also re-discovered Syncthing, a file synchronization software. Amazingly, I was having trouble transferring a single file between two phones. I couldn't use Bluetooth (not sure why), the "Wifi sharing" app was available only on one phone (and is proprietary, and has a limit of 4MB files), and everything else requires an account, the cloud, or cabling. So. Just heading to f-droid, install syncthing, flash a few qr-codes around and voil : files are copied over! Pretty amazing: the files were actually copied over the local network, using IPv6 link-local addresses, encryption and the DHT. Which is a real geeky way of saying it's completely fast, secure and fast. Now, I found a few usability issues, so much that I wrote a whole usability story for the developers, which were really appreciative of my review. Some of the issues were already fixed, others were pretty minor. Syncthing has a great community, and it seems like a great project I encourage everyone to get familiar with.

Battery stats The battery-status project I mentionned previously has been merged with the battery-stats project (yes, the names are almost the same, which is confusing) and so I had to do some work to fix my Python graph script, which was accepted upstream and will be part of Debian officially from now on, which is cool. The previous package was unofficial. I have also noticed that my battery has a significantly than when I wrote the script. Whereas it was basically full back then, it seems now it has lost almost 15% of its capacity in about 6 months. According to the calculations of the script:

this battery will reach end of life (5%) in 935 days, 19:07:58.336480, on 2018-10-23 12:06:07.270290

Which is, to be fair, a good life: it will somewhat work for about three more years.

Playlist, git-annex and MPD in Python On top of my previously mentioned photos-import script, I have worked on two more small programs. One is called get-playlist and is an extension to git-annex to easily copy to the local git-annex repository all files present in a given M3U playlist. This is useful for me because my phone cannot possibly fit my whole MP3 collection, and I use playlists in GMPC to tag certain files, particularly the Favorites list which is populated by the "star" button in the UI. I had a lot of fun writing this script. I started using elpy as an IDE in Emacs. (Notice how Emacs got a new webpage, which is a huge improvement was had been basically unchanged since the original version, now almost 20 years old, and probably written by RMS himself.) I wonder how I managed to stay away from Elpy for so long, as it glues together key components of Emacs in an elegant and functional bundle:

• Company: the "vim-like" completion mode i had been waiting for forever
• Jedi: context-sensitive autocompletion for Python
• Flymake: to outline style and syntax errors (unfortunately not the more modern Flycheck)
• inline documentation...

In short, it's amazing and makes everything so much easier to work with that I wrote another script. The first program wouldn't work very well because some songs in the playlists had been moved, so I made another program, this time to repair playlists which refer to missing files. The script is simply called fix-playlists, and can operate transparently on multiple playlists. It has a bunch of heuristics to find files and uses a MPD server as a directory to search into. It can edit files in place or just act as a filter.

Useful snippets Writing so many scripts, so often, I figured I needed to stop wasting time always writing the same boilerplate stuff on top of every file, so I started publishing Yasnippet-compatible file snippets, in my snippets repository. For example, this report is based on the humble lts snippet. I also have a base license snippet which slaps the AGPLv3 license on top of a Python file. But the most interesting snippet, for me, is this simple script snippet which is a basic scaffolding for a commandline script that includes argument processing, logging and filtering of files, something which I was always copy-pasting around.

Other projects And finally, a list of interesting issues en vrac:

• there's a new Bootstrap 4 theme for Ikiwiki. It was delivering content over CDNs, which is bad for privacy issues, so I filed an issue which was almost immediately fixed by the author!
• I found out about BitHub, a tool to make payments with Bitcoins for patches submitted on OWS projects. It wasn't clear to me where to find the demo, but when I did, I quickly filed a PR to fix the documentation. Given the number of open PRs there and the lack of activity, I wonder if the model is working at all...
• a fellow Debian Developer shared his photos workflow, which was interesting to me because I have my own peculiar script, which I never mentionned here, but which I ended up sharing with the author

• Confidentiality: Messages are encrypted, so they cannot be read by someone eavesdropping.
• Integrity: Messages are protected against corruption, whether random or malicious.
• Authentication: You know who sent a given message (although you'll need to verify this out-of-band, of course). Note that while this usually implies non-repudiation, see below.
• Participant consistency: In a group chat, everybody sees the same list of people.
• Destination validation: Messages you got were intended for you.
• Forward secrecy: If someone gets to your keys (including long-term and current session keys), they can't decrypt earlier messages.
• Backward secrecy (aka future secrecy): If someone gets to your keys, they can't decrypt later messages.
• Causality preservation: Messages cannot come out-of-order.
• Message repudiation: You cannot cryptographically prove to others that someone sent a given message, even though you know it yourself. (This is possible because at the same time you get a signed message, you also get what would be needed to fake that signature yourself.)
• Message unlinkability: Even if you could prove to others that someone sent a given message (e.g. by arguing only they had that information), that doesn't help proving it for any other messages.
• Participation repudiation: There's no way to cryptographically prove you were in a group chat, even if all the other members of it conspire.
• Asynchronicity: Clients don't need to be online at the same time to send messages.