Python3 GTK3 TextView Drag-and-Drop Example

Just a small finger exercise …

#!/usr/bin/env python3

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk
import os
import sys

class GUI:
    def __init__(self):
        self.window = Gtk.Window()
        self.window.connect('destroy', Gtk.main_quit)
        self.textview = Gtk.TextView()
        self.textview.connect("drag-data-received", self.on_drag)
        self.window.add(self.textview)
        self.window.show_all()
        self.buffer = self.textview.get_buffer()

    def on_drag(
        self,
        widget,
        drag_context,
        x,
        y,
        data,
        info,
        time
    ):
        text = data.get_text()
        print("DEBUG: text = %s" % text)
        self.buffer.set_text("")

def main():
    app = GUI()
    Gtk.main()

if __name__ == "__main__":
    sys.exit(main())

There is no such Thing as „End-to-End-Encryption“

A communication between two communication partners, which on a technical level can also be called „endpoints“ or „ends“ of a connection (or more general, of a channel of communication), is either encrypted, or it is not. If somewhere in between the „ends“ of the connection, encryption takes place, such that there exist parts of the entire communication channel which are not affected by it, then the comunication itself is not encrypted.

There is no debate about „end-to-end encryption – yes or no“ but only about „encryption – yes or no“, and the answer to that question must clearly be „yes“. Any service of communication that claims to offer encryption, except that this encryption „is not end-to-end“, does not offer encryption at all.

This is a surprisingly simple resolution of an apparently difficult question.

Bourne to Bourne Again Shell Forward Compatibility

Introduction

In this article i try to find out, if Bourne Shell scripts are runnable in Bourne Again Shell without modification. If not, i advice on how to modify the code so that it runs on both Shells.

An interpreter for some variant of Bourne Shell is available as an executable /bin/sh on most Linux and UNIX systems. Writing Bourne Shell script has the possible advantage that such a script can work on all these systems with no changes to the code; be it Linux, AIX, FreeBSD, initramfs or a string passed to a C library call system(3), expressions such as

  • echo hello | wc
  • my_pid=$$

or

  • exit 1

would always work.

Recently, i used GNU Bourne Again Shell for scripting, and i wondered if all of my longstandingly Bourne Shell established practices were seamlessly portable. So i did some research, and in this article i highlight some code constructs i found that work in Bourne Shell and do not work as expected in Bourne Again Shell. Code currently interpreted by /bin/sh and containing such constructs must be reviewed if will be interpreted by /bin/bash.

As it stands, i will focus on reserved words and built-ins, brace expansion and pipeline subprocesses.

Comparing Distinguished LDAP Names

In a Bourne Shell script, a distinguished name (DN) for performing an LDAP-query is held in a variable:

dn="cn=Malmø,ou=County Capitals,dc=Sweden,dc=Europe"

For the purpose of demonstration, this example DN contains a non-ASCII character.

Let’s write a Bourne Shell function that escapes such special characters as requested by RFC 4514 using perl’s Net::LDAP::Util:

canonical_dn() {
    perl -s -MNet::LDAP::Util -e '
        print Net::LDAP::Util::canonical_dn($dn, mbcescape=>1)
    ' -- -dn="$1"
}

Let’s test the function:

echo "Unescaped DN: $dn"
echo "Escaped DN:   $(canonical_dn "$dn")"

The expected output is:

Unescaped DN: cn=Malmø,ou=County Capitals,dc=Sweden,dc=Europe
Escaped DN:   CN=Malm\c3\b8,OU=County Capitals,DC=Sweden,DC=Europe

With a normalized notation, DN values are more robust when sending them to external applications such as the OpenLDAP client tools (ldapsearch & Co.), and certain operations on DNs inside the shellscript itself become a bit more feasible.

But note: For various reasons, DNs can not be reliaby compared for equality, even if both are normalized using canonical_dn. For example, attributes can have a long and a short name, both are valid when denoting a DN, and the OID of an attribute can also be used when denoting a DN. The following DNs address identical entries:

  • cn=Malmø,ou=County Capitals,dc=Sweden,dc=Europe
  • commonName=Malmø,ou=County Capitals,dc=Sweden,dc=Europe
  • 2.5.4.3=Malmø,ou=County Capitals,dc=Sweden,dc=Europe

The information that all these notations of the same attribute commonName are identical is contained in the schema of the LDAP database that is being queried, and neither canonical_dn nor the shellscript can apply this information, this can only be done by an LDAP server.

This made me wonder if there is a canonical way of comparing two DN representations for identity using interaction with an LDAP directory access server. Apparently this is not so:

  • RFC 2251 lists „bind“, „search“, „modify“, „add“, „delete“ and „modify DN“ as supported message types.
  • RFC 2253 makes no mention of DN comparison.
  • I am not aware of an extended request for comparing DNs, at least not one that was widespread across implementations.  ldapwiki.com lists „cancel“, „password modify“, „StartTLS“ and „Who am I“ as known examples, ldap.com additionally lists „Start Transaction“ and „End Transaction“, calling them „standard extended operation types“.

Was manche Leute in ihrer „Datenschutzerklärung“ stehen haben …

Gesehen auf https://t3n.de/datenschutz/ am 23. Juli 2020, Zitat: „Eine Einwilligung in den Einsatz des Facebook-Pixels darf nur von Nutzern, die älter als 13 Jahre alt sind, erklärt werden. Falls Sie jünger sind, bitten wir Sie, Ihre Erziehungsberechtigten um Erlaubnis zu fragen.“

Das von t3n als „Datenschutzerklärung“ bezeichnete Dokument ist 110991 Zeichen in 13945 Wörtern lang; das obige Zitat erfolgt nach 40% des gesamten Texts bzw. nach 5681 Wörtern, die man hat lesen müssen, um bei dieser Information anzukommen. Eine so relevante Information, die nämlich mitteilt, dass unter 13 Jahre alte Benutzer die Webseite nur mit Einwilligung ihrer Erziehungsberechtigten verwenden dürfen, halte ich persönlich für reichlich unzugänglich.

Noch ein Zitat aus besagtem Dokument: „Facebook Inc. mit Sitz in den USA ist für das us-europäische Datenschutzübereinkommen „Privacy Shield“ zertifiziert, welches die Einhaltung des in der EU geltenden Datenschutzniveaus gewährleistet.“

Diese Aussage ist mit einem Urteil des europäischen Gerichtshofs vom 16. Juli 2020 als falsch festgestellt, und eine Änderung des Dokuments wird nötig sein. Das wäre vieleicht ein guter Anlass, auch an anderen Stellen in diesem Dokument für mehr Klarheit zu sorgen.

Sitzgelegenheit im Garten

Ich bin recht viel Zuhause die Tage 🙂 Da komme ich ab und zu auch wieder zum Basteln.

Vor ein paar Jahren hatte ich eine historische Parkbank aufwändig restauriert, wobei ich vom Gestell etwa vierzig Prozent abschneiden musste, da es unrettbar korrodiert war. Das Holz hatte ich mit handelsüblichen Kiefer-Leisten, geschliffen und mit Wetterschutz-Farbe ersetzt. Dann stand das Ding erstmal nur herum, da saß ich vielleicht dreimal im Jahr drauf, wenn’s hochkommt … fand ich immer schade. Weiterlesen … »

Endlich Sommer …

… im April. 😯

Determining User Access on a Linux Filesystem with „Classic Permissions“

Introduction

Looking at a Linux filesystem, checking if a certain file or directory is accessible for reading, writing or executing by certain users or groups poses interesting challenges.

Let the basic and seemingly simple question be: „Given a user X and a file Y, can it be determined if X has access to Y, and if yes, how can it be determined?“ A simple answer was: „Let X try to access Y, and if it does not work, X does not have that kind of access.“ However, this may not be feasible: The users, files and directories in question may not exist yet. More generally, access by users to files and directories should be predictable; appropriate access restrictions should be placed in advance, not after exposing possibly sensitive information. Also, certain types of access, such as deleting a file or directory, can not be simulated in a safe manner.

Moreover, a test procedure that just involves „trying to access the file“ may be incomplete: Just because the way the test procedure has attempted access did not succeed, that does not mean that there is no procedure at all by which the user in question can access the file.

This article investigates Linux filesystems that implement the semantics of „classic UNIX permissions“ in an effort to find more exhaustive methods of determining access.