Lasso log using the GLib logging API and the Python binding install a
hook to delegate logging to a Python logger named "lasso".
During the logging call the error indicator can be set to signal an
exception. The indicator will still be set when we return from the Lasso
API call, and is not handled by the Python wrapping of the C functions.
If our function returns a non-NULL value, the Python interpreter will
raise because this situation is forbidden.
To prevent it, if we detect that an exception occurred during logging
calls, we print it to stderr, clear the error indicator and return
immediately.
The key encryption padding algorithm is now configurable, the default
being changed to OAEP. It's possible to set the default through
./configure with:
--with-default-key-encryption-method=[rsa-pkcs1|rsa-oaep]
at initialization time with an environment variable:
LASSO_DEFAULT_KEY_ENCRYPTION_METHOD=[rsa-pkcs1|rsa-oaep]
or at runtime for a service provider:
lasso_provider_set_key_encryption_method(LassoProvider *provider,
LassoKeyEncryptionMethod key_encryption_method)
The setting is global for all encrypted nodes (Assertion or NameID).
The __str__ method called itself, resulting in an RecursionError.
======================================================================
ERROR: test14 (__main__.BindingTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./binding_tests.py", line 336, in test14
assert isinstance(str(cm.exception), str)
File "../lasso.py", line 69, in __str__
return '<lasso.%s: %s>' % (self.__class__.__name__, self)
File "../lasso.py", line 69, in __str__
return '<lasso.%s: %s>' % (self.__class__.__name__, self)
File "../lasso.py", line 69, in __str__
return '<lasso.%s: %s>' % (self.__class__.__name__, self)
[Previous line repeated 489 more times]
File "../lasso.py", line 68, in __str__
if sys.version_info >= (3,):
RecursionError: maximum recursion depth exceeded in comparison
----------------------------------------------------------------------
so that lasso.py, lasso/types.c and liblasso.so.3.13.0
build reproducibly
in spite of indeterministic filesystem readdir order.
For some reason, lasso/extract_sections.py lasso/extract_symbols.py
do not need such patches to get a reproducible openSUSE package.
See https://reproducible-builds.org/ for why this is good.
This patch was done while working on reproducible builds for openSUSE.
License: MIT
Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de>
debian/rules supposed that lasso Makefile would always prefer python2 to
python3, it's not the case anymore. Also recent python3 improvements to
bindings scripts did not work with python 3.5 on jessie (on jessie/3.5
default open() encoding is still ASCII not UTF-8 as with the default
UTF-8 of later python3 versions).
While porting other Python code in the repo to run under Py3 (as well
as Py2) it was discovered there were a number of other Python scripts
which also needed porting. However these scripts are never invoked
during a build so there was no easy way to test the porting work. I
assume these scripts are for developers only and/or are
historical. Because there was no way for me to test the porting
changes on these scripts I did not want to include the changes in the
patch for the Py3 porting which fixed scripts that are invoked during
the build (the former patch is mandatory, this patch is optional at
the moment). I did verify the scripts compile cleanly under both Py2
and Py3, however it's possible I missed porting something or the error
does not show up until run-time.
Examples of the required changes are:
* Replace use of the built-in function file() with open(). file()
does not exist in Py3, open works in both Py2 and Py3. The code was
also modified to use a file context manager (e.g. with open(xxx) as
f:). This assures open files are properly closed when the code block
using the file goes out of scope. This is a standard modern Python
idiom.
* Replace all use of the print keyword with the six.print_()
function, which itself is an emulation of Py3's print function. Py3
no longer has a print keyword, only a print() function.
* The dict methods .keys(), .values(), .items() no longer return a
list in Py3, instead they return a "view" object which is an
iterator whose result is an unordered set. The most notable
consequence is you cannot index the result of these functions like
your could in Py2 (e.g. dict.keys()[0] will raise a run time
exception).
* Replace use of StringIO.StringIO and cStringIO with
six.StringIO. Py3 no longer has cStringIO and the six variant
handles the correct import.
* Py3 no longer allows the "except xxx, variable" syntax, where
variable appering after the comma is assigned the exception object,
you must use the "as" keyword to perform the variable assignment
(e.g. execpt xxx as variable)
* Python PEP 3113 removed tuple parameter unpacking. Therefore you can
no longer define a formal parameter list that contains tuple
notation representing a single parameter that is unpacked into
multiple arguments.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
Python and Emacs (and others?) recognize a special directive line in a
file that identifies what encoding the file is encoded in. See Python
PEP 263. For example:
The general form of the directive is:
where xxx is the name of a codec. Python codec names are lower case
with underscores used to seperate words.
In both Python and Emacs one can create aliases for the codecs so you
can use an alternate name to refer to the same codec.
Python is forgiving with respect to case, underscore and
hyphens. Python will automatically create an alias for a codec name by
downcasing it and replacing hyphens with underscores, thus "UTF-8" is
actually an alias for the "utf_8" codec. Unfortunately emacs does not
automatically create such aliases, although one can add aliases via a
custom initialization file, but doing so requires every user using
emacs to edit the files to manually create their own aliases.
If you try to write a file in emacs with the "UTF-8" codec name it
won't recognize it as "utf-8", instead you'll get errors like this:
Warning (mule): Invalid coding system ‘UTF-8’ is specified
for the current buffer/file by the :coding tag.
It is highly recommended to fix it before writing to a file.
and you must force the file to be written by responding to additional
propmpts.
This patch simply downcases the the "UTF-8" codec name to "utf-8" so
that both Python and Emacs will accept the codec name.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
Commit 6f617027e added a duplicate definition of the LogoutTestCase
class containing only 1 test which shaddowed the original
LogoutTestCase containing 4 tests. The logoutSuite variable was also
shadowed and the allTests variable contained a duplicate of
logoutSuite causing the 2nd definition of LogoutTestCase to be run
twice.
Not only were the original 4 tests not being run but the entire unit
test in profiles_tests.py was failing under Python3. This is because
the unittest code in Py3 deletes a test from it's list of tests to run
once it's been run. The second time the logoutSuite was invoked it no
longer contained any tests which caused an exception to be raised
because there were no tests to be run.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
During the build if the Python3 interpreter is used a number of
scripts will fail because they were never ported from Py2 to Py3. In
general we want Python code to be compatible with both Py2 and
Py3. This patch brings the scripts up to date with Py3 but retains
backwards compatibility with Py2 (specifically Py 2.7, the last Py2
release).
Examples of the required changes are:
* Replace use of the built-in function file() with open(). file()
does not exist in Py3, open works in both Py2 and Py3. The code was
also modified to use a file context manager (e.g. with open(xxx) as
f:). This assures open files are properly closed when the code block
using the file goes out of scope. This is a standard modern Python
idiom.
* Replace all use of the print keyword with the six.print_()
function, which itself is an emulation of Py3's print function. Py3
no longer has a print keyword, only a print() function.
* The dict methods .keys(), .values(), .items() no longer return a
list in Py3, instead they return a "view" object which is an
iterator whose result is an unordered set. The most notable
consequence is you cannot index the result of these functions like
your could in Py2 (e.g. dict.keys()[0] will raise a run time
exception).
* Replace use of StringIO.StringIO and cStringIO with
six.StringIO. Py3 no longer has cStringIO and the six variant
handles the correct import.
* Py3 no longer allows the "except xxx, variable" syntax, where
variable appering after the comma is assigned the exception object,
you must use the "as" keyword to perform the variable assignment
(e.g. execpt xxx as variable)
Note: the modifications in this patch are the minimum necessary to get
the build to run with the Py3 interpreter. There are numerous other
Python scripts in the repo which need Py3 porting as well but because
they are not invoked during a build they will be updated in a
subsequent patch.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
The configure script allows you to specify the python interpreter to
use via the --with-python option. There were several places where the
python interpreter was implicity invoked without using the specified
version. This can create a number of problems in an environment with
multiple python versions as is the case during the transition from
Python 2 to Python 3. Python 2 is not compatible with Python
3. Lasso's Python code is supposed to be compatible with both
versions. But during the build and when running the unit tests it is
essential the same interpreter be used consistently otherwise you can
have problems.
This patch assures whenever python is invoked it does so via the
$(PYTHON) configuration variable.
What about shebang lines (e.g #/usr/bin/python) at the top of scripts?
Python PEP 394 (https://www.python.org/dev/peps/pep-0394/) covers
this. Basically it says if a script is compatible only with Py2 the
shebang should be #/usr/bin/python2, if only compatible with Py3 the
shebang should be #/usr/bin/python3. However, if the script is
compatible with both versions it can continue to use the
compatible with both Py2 and Py3.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
Frédéric Péters
Benjamin Dauvergne
Jakub Hrozek
Bernhard M. Wiedemann
Tomohiro "Tomo-p" KATO
John Dennis