git clone https://github.com/frankmorgner/vsmartcard.git
cd vsmartcard
-# fetch the applets that are in the submodules
-git submodule init
-git submodule update
+git submodule update --init --recursive
We use Android Studio8 to build and deploy the application. Use
@@ -268,7 +266,7 @@
diff --git a/docs/_images/inheritance-285e17a8f890c78c473daa9db430b4cda74f6cb7.png b/docs/_images/inheritance-285e17a8f890c78c473daa9db430b4cda74f6cb7.png
deleted file mode 100644
index 2585a928..00000000
Binary files a/docs/_images/inheritance-285e17a8f890c78c473daa9db430b4cda74f6cb7.png and /dev/null differ
diff --git a/docs/_images/inheritance-285e17a8f890c78c473daa9db430b4cda74f6cb7.png.map b/docs/_images/inheritance-285e17a8f890c78c473daa9db430b4cda74f6cb7.png.map
deleted file mode 100644
index a77f88b5..00000000
--- a/docs/_images/inheritance-285e17a8f890c78c473daa9db430b4cda74f6cb7.png.map
+++ /dev/null
@@ -1,4 +0,0 @@
-
diff --git a/docs/_images/inheritance-5827e1a05433ba14df2d516741c83a340d46b696.png b/docs/_images/inheritance-5827e1a05433ba14df2d516741c83a340d46b696.png
deleted file mode 100644
index 9d843ca7..00000000
Binary files a/docs/_images/inheritance-5827e1a05433ba14df2d516741c83a340d46b696.png and /dev/null differ
diff --git a/docs/_images/inheritance-5827e1a05433ba14df2d516741c83a340d46b696.png.map b/docs/_images/inheritance-5827e1a05433ba14df2d516741c83a340d46b696.png.map
deleted file mode 100644
index e5e2cbde..00000000
--- a/docs/_images/inheritance-5827e1a05433ba14df2d516741c83a340d46b696.png.map
+++ /dev/null
@@ -1,4 +0,0 @@
-
diff --git a/docs/_images/inheritance-5c600c60a9fcc658bb9a017dd609c3bff8e456b3.png b/docs/_images/inheritance-5c600c60a9fcc658bb9a017dd609c3bff8e456b3.png
deleted file mode 100644
index b6a07d7a..00000000
Binary files a/docs/_images/inheritance-5c600c60a9fcc658bb9a017dd609c3bff8e456b3.png and /dev/null differ
diff --git a/docs/_images/inheritance-5c600c60a9fcc658bb9a017dd609c3bff8e456b3.png.map b/docs/_images/inheritance-5c600c60a9fcc658bb9a017dd609c3bff8e456b3.png.map
deleted file mode 100644
index 938dc5ac..00000000
--- a/docs/_images/inheritance-5c600c60a9fcc658bb9a017dd609c3bff8e456b3.png.map
+++ /dev/null
@@ -1,4 +0,0 @@
-
diff --git a/docs/_images/inheritance-95149f9804291dbbbe502519b9ab8d95f3e28f93.png b/docs/_images/inheritance-95149f9804291dbbbe502519b9ab8d95f3e28f93.png
deleted file mode 100644
index 53909d0f..00000000
Binary files a/docs/_images/inheritance-95149f9804291dbbbe502519b9ab8d95f3e28f93.png and /dev/null differ
diff --git a/docs/_images/inheritance-95149f9804291dbbbe502519b9ab8d95f3e28f93.png.map b/docs/_images/inheritance-95149f9804291dbbbe502519b9ab8d95f3e28f93.png.map
deleted file mode 100644
index 082f9c3c..00000000
--- a/docs/_images/inheritance-95149f9804291dbbbe502519b9ab8d95f3e28f93.png.map
+++ /dev/null
@@ -1,3 +0,0 @@
-
diff --git a/docs/_images/inheritance-c92efbd974214a247217ba79cf0775fb65c344af.png b/docs/_images/inheritance-c92efbd974214a247217ba79cf0775fb65c344af.png
deleted file mode 100644
index 70b2792c..00000000
Binary files a/docs/_images/inheritance-c92efbd974214a247217ba79cf0775fb65c344af.png and /dev/null differ
diff --git a/docs/_images/inheritance-c92efbd974214a247217ba79cf0775fb65c344af.png.map b/docs/_images/inheritance-c92efbd974214a247217ba79cf0775fb65c344af.png.map
deleted file mode 100644
index d0bd8c2e..00000000
--- a/docs/_images/inheritance-c92efbd974214a247217ba79cf0775fb65c344af.png.map
+++ /dev/null
@@ -1,4 +0,0 @@
-
diff --git a/docs/_images/inheritance-c95de3c82405e783e52102c0d9ccbc16f7e48d7c.png b/docs/_images/inheritance-c95de3c82405e783e52102c0d9ccbc16f7e48d7c.png
deleted file mode 100644
index 835d1a40..00000000
Binary files a/docs/_images/inheritance-c95de3c82405e783e52102c0d9ccbc16f7e48d7c.png and /dev/null differ
diff --git a/docs/_images/inheritance-c95de3c82405e783e52102c0d9ccbc16f7e48d7c.png.map b/docs/_images/inheritance-c95de3c82405e783e52102c0d9ccbc16f7e48d7c.png.map
deleted file mode 100644
index 99e13ee6..00000000
--- a/docs/_images/inheritance-c95de3c82405e783e52102c0d9ccbc16f7e48d7c.png.map
+++ /dev/null
@@ -1,4 +0,0 @@
-
diff --git a/docs/_images/inheritance-d51eb1f410a57b99d3b85ed60b3f73a1a03a39de.png b/docs/_images/inheritance-d51eb1f410a57b99d3b85ed60b3f73a1a03a39de.png
deleted file mode 100644
index 06da744e..00000000
Binary files a/docs/_images/inheritance-d51eb1f410a57b99d3b85ed60b3f73a1a03a39de.png and /dev/null differ
diff --git a/docs/_images/inheritance-d51eb1f410a57b99d3b85ed60b3f73a1a03a39de.png.map b/docs/_images/inheritance-d51eb1f410a57b99d3b85ed60b3f73a1a03a39de.png.map
deleted file mode 100644
index b6ba07eb..00000000
--- a/docs/_images/inheritance-d51eb1f410a57b99d3b85ed60b3f73a1a03a39de.png.map
+++ /dev/null
@@ -1,6 +0,0 @@
-
diff --git a/docs/_sources/ACardEmulator/README.txt b/docs/_sources/ACardEmulator/README.txt
index 66edc24d..5ff5b0ce 100644
--- a/docs/_sources/ACardEmulator/README.txt
+++ b/docs/_sources/ACardEmulator/README.txt
@@ -134,9 +134,7 @@ submodules::
git clone https://github.com/frankmorgner/vsmartcard.git
cd vsmartcard
- # fetch the applets that are in the submodules
- git submodule init
- git submodule update
+ git submodule update --init --recursive
We use `Android Studio`_ to build and deploy the application. Use
:menuselection:`File --> Open` to select :file:`vsmartcard/ACardEmulator`.
diff --git a/docs/_sources/ccid/README.txt b/docs/_sources/ccid/README.txt
index 7cf142e9..4f3ed3c6 100644
--- a/docs/_sources/ccid/README.txt
+++ b/docs/_sources/ccid/README.txt
@@ -168,12 +168,6 @@ tools.
\texttt{/dev/gadget/ep2-bulk}\\
\texttt{/dev/gadget/ep3-bulk}\\};
-
-Running the USB CCID Emulator has the following dependencies:
-
-- Linux Kernel with GadgetFS_
-- OpenSC_
-
Whereas using the USB CCID Emulator on the host system as smart card reader only
needs a usable PC/SC middleware with USB CCID driver. This is the case for most
modern Windows and Unix-like systems by default.
@@ -266,7 +260,12 @@ modern Windows and Unix-like systems by default.
.. include:: autotools.txt
The USB CCID Emulator depends on :program:`libopensc`, which is automatically
-built from a snapshot of the OpenSC source code and then statically linked.
+built from a snapshot of the OpenSC_ source code and then statically linked.
+
+Running the USB CCID Emulator has the following dependencies:
+
+- Linux Kernel with GadgetFS_
+- OpenSSL_ 1.0.0 or later
=================
@@ -334,6 +333,7 @@ Notes and References
.. _`GadgetFS`: http://www.linux-usb.org/gadget/
.. _`OpenSC`: https://github.com/frankmorgner/OpenSC
+.. _`OpenSSL`: https://www.openssl.org
.. _`libccid`: https://ccid.apdu.fr/
.. _`Windows USB CCID driver`: http://msdn.microsoft.com/en-us/windows/hardware/gg487509
.. _`OpenMoko Wiki`: http://wiki.openmoko.org/wiki/Building_Gadget_USB_Module
diff --git a/docs/_sources/index.txt b/docs/_sources/index.txt
index 5c4df01a..bfb7294f 100644
--- a/docs/_sources/index.txt
+++ b/docs/_sources/index.txt
@@ -61,17 +61,17 @@ have a look at these programming guides and try yourself:
virtualsmartcard/api
-.. image:: https://img.shields.io/travis/frankmorgner/vsmartcard/master.svg?label=Travis%20CI%20build
- :target: https://travis-ci.org/frankmorgner/vsmartcard
- :alt: Travis CI Build Status Image
+.. image:: https://img.shields.io/github/actions/workflow/status/frankmorgner/vsmartcard/ci.yml?branch=master&label=Ubuntu%2FmacOS&logo=github
+ :target: https://github.com/frankmorgner/vsmartcard/actions/workflows/ci.yml?branch=master
+ :alt: GitHub CI status
.. image:: https://img.shields.io/appveyor/ci/frankmorgner/vsmartcard/master.svg?label=AppVeyor%20build
:target: https://ci.appveyor.com/project/frankmorgner/vsmartcard
- :alt: AppVeyor CI Build Status Image
+ :alt: AppVeyor CI status
.. image:: https://img.shields.io/coverity/scan/3987.svg?label=Coverity%20scan
:target: https://scan.coverity.com/projects/3987
- :alt: Coverity Scan Status
+ :alt: Coverity Scan status
Download
diff --git a/docs/_sources/pcsc-relay/README.txt b/docs/_sources/pcsc-relay/README.txt
index c81c0eb6..e7dd8ba3 100644
--- a/docs/_sources/pcsc-relay/README.txt
+++ b/docs/_sources/pcsc-relay/README.txt
@@ -16,7 +16,7 @@ PC/SC Relay
Welcome to PC/SC Relay. The purpose of PC/SC Relay is to relay a smart
card using an contact-less interface. Currently the following contact-less
-emulators are supported:
+**emulators** are supported:
- `Hardware supported by libnfc`_
- OpenPICC_
@@ -24,7 +24,7 @@ emulators are supported:
Command APDUs are received with the contact-less interface and relayed. The
Response APDUs are then sent back via RFID. The contact-less data will be
-relayed to one of the following:
+relayed to one of the following **connectors**:
- to a *real* smart card inserted into one of the systems' smart card readers.
The smart card reader must be accessible with PC/SC. The smart card may be
@@ -33,6 +33,32 @@ relayed to one of the following:
smart card's native interface is used and (despite its name) PC/SC Relay
does not need to access PC/SC in this case.
+..
+ http://www.plantuml.com/plantuml/txt/SoWkIImgAStDuNBDBSr9BCalKj2rKr0gI2vErYrApKciL5AmKd3EpyrDp4jHS0nm2UL2bWEg1KhcvQKc0pLoGLcOHc3eWTjbfH2KMboGdrUS2Z7S8JKl1UWO0000
+
+ @startuml
+ skinparam responseMessageBelowArrow true
+ Emulator -> "pcsc-relay" : Command APDU
+ "pcsc-relay" -> Connector
+ Connector -> "pcsc-relay"
+ "pcsc-relay" -> Emulator : Response APDU
+ @enduml
+
+::
+
+ ┌────────┐ ┌──────────┐ ┌─────────┐
+ │Emulator│ │pcsc-relay│ │Connector│
+ └───┬────┘ └────┬─────┘ └────┬────┘
+ │ Command APDU │ │
+ │ ───────────────────> │
+ │ │ ───────────────────>│
+ │ │ <───────────────────│
+ │ Response APDU │ │
+ │ <─────────────────── │
+ ┌───┴────┐ ┌────┴─────┐ ┌────┴────┐
+ │Emulator│ │pcsc-relay│ │Connector│
+ └────────┘ └──────────┘ └─────────┘
+
.. tikz:: Debug, Analyze and Emulate with PC/SC Relay
:stringsubst:
:libs: arrows, calc, fit, patterns, plotmarks, shapes.geometric, shapes.misc, shapes.symbols, shapes.arrows, shapes.callouts, shapes.multipart, shapes.gates.logic.US, shapes.gates.logic.IEC, er, automata, backgrounds, chains, topaths, trees, petri, mindmap, matrix, calendar, folding, fadings, through, positioning, scopes, decorations.fractals, decorations.shapes, decorations.text, decorations.pathmorphing, decorations.pathreplacing, decorations.footprints, decorations.markings, shadows
diff --git a/docs/_sources/virtualsmartcard/README.txt b/docs/_sources/virtualsmartcard/README.txt
index cb2c29d6..d2e8e9f4 100644
--- a/docs/_sources/virtualsmartcard/README.txt
+++ b/docs/_sources/virtualsmartcard/README.txt
@@ -103,7 +103,7 @@ Depending on your usage of the |vpicc| you may need to install the following:
- Python_
- pyscard_ (relaying a local smart card with `--type=relay`)
-- PyCryptodome_, PBKDF2_, PIL_, readline_ or PyReadline_ (emulation of electronic
+- PyCryptodome, PBKDF2_, PIL_, readline_ or PyReadline_ (emulation of electronic
passport with `--type=ePass`)
- OpenPACE_ (emulation of German identity card with `--type=nPA`)
- libqrencode_ (to print a QR code on the command line for `vpcd-config`; an
@@ -136,7 +136,7 @@ card reader with an :file:`Info.plist`::
make install
================================================================================
-Building and installing |vpcd| on Windows
+Building |vpcd| on Windows
================================================================================
.. versionadded:: 0.7
@@ -145,11 +145,15 @@ Building and installing |vpcd| on Windows
PC/SC.
For the Windows integration we extended `Fabio Ottavi's UMDF Driver for a
-Virtual Smart Card Reader`_ with a |vpcd| interface. To build |vpcd| for
-Windows we use `Windows Driver Kit 10 and Visual Studio 2015`_. The vpcd
-installer requires the `WiX Toolset 3.10`_. If you choose
+Virtual Smart Card Reader`_ with a |vpcd| interface. If you choose
to download the `Windows binaries`_, you may directly jump to step 4.
+In the CI environment, we're building |vpcd| for Windows with Visual Studio
+Community 2019 with SDK/WDK for Windows 11. (The WDK version needs to match
+at least your targeted version of Windows, see this `guide for installing VS
+with WDK`_) The vpcd installer additionally
+requires the `WiX Toolset 3.10`_ to be installed.
+
1. Clone the git repository and make sure it is initialized with all
submodules::
@@ -166,11 +170,6 @@ to download the `Windows binaries`_, you may directly jump to step 4.
the installer (:file:`BixVReaderInstaller.msi`) in
:file:`virtualsmartcard\\win32\\BixVReaderInstaller\\bin\\*Release`
-4. To install |vpcd|, double click :file:`BixVReaderInstaller.msi`. Since we
- are currently not signing the Installer, this will yield a warning about an
- unverified driver software publisher on Windows 8 and later. Click
- :guilabel:`Install this driver software anyway`.
-
For debugging |vpcd| and building the driver with an older version of Visual
Studio or WDK please see `Fabio Ottavi's UMDF Driver for a Virtual Smart Card
Reader`_ for details.
@@ -179,6 +178,9 @@ All of Fabio's card connectors are still available, but inactive by default
(see `Configuring vpcd on Windows`_ below).
+.. include:: install.txt
+
+
********************************************************************************
Using the Virtual Smart Card
********************************************************************************
@@ -300,6 +302,38 @@ through the PC/SC API. You can use the :command:`opensc-explorer` or
provide scripts for testing with npa-tool_ and PCSC-Lite's smart card
reader driver tester.
+--------------------------------------------------------------------------------
+Testing |vpicc| -t ePass
+--------------------------------------------------------------------------------
+
+A simple tool to test |BAC| is available for Python 2.7. On Ubuntu, its
+requiremets are installed as follows::
+
+ sudo apt-get install python2.7-dev
+ curl https://bootstrap.pypa.io/pip/2.7/get-pip.py -o get-pip.py
+ python2.7 get-pip.py
+ python2.7 -m pip install pycryptodomex pyscard
+ python2.7 readpass.py --no-gui
+ git clone https://github.com/henryk/cyberflex-shell
+ cd cyberflex-shell
+
+Now we can create and run a small script::
+
+ echo "select_application a0000002471001" > script.txt
+ echo "perform_bac L898902C<3UTO6908061F9406236ZE184226B<<<<<14" >> script.txt
+ python2.7 cyberflex-shell.py script.txt
+
+The tool will wait for a (virtual) smart card to appear. Start |vpicc| and make
+sure to configure it with the correct MRZ, i.e.
+``P
- USB CCID Emulator — vsmartcard 2021-04-28 documentation
+ USB CCID Emulator — vsmartcard 2023-10-01 documentation
@@ -12,10 +12,6 @@
-
-
-
-
@@ -24,6 +20,10 @@
+
+
+
+
@@ -144,7 +144,7 @@
@@ -201,7 +201,7 @@
transmitting (SCardTransmit) specially crafted APDUs. Only the alternative
initialization of PACE using SCardControl requires patching the driver
(available for libccid, see patches). The pseudo APDUs with no need for
-patches are defined as follows (see BSI TR-03119 1.36 p. 33-34):
+patches are defined as follows (see BSI TR-03119 1.37 p. 33-34):
@@ -272,12 +272,7 @@
Software stack of the USB CCID Emulator running on the OpenMoko Neo FreeRunner
-
Running the USB CCID Emulator has the following dependencies:
Whereas using the USB CCID Emulator on the host system as smart card reader only
+
Whereas using the USB CCID Emulator on the host system as smart card reader only
needs a usable PC/SC middleware with USB CCID driver. This is the case for most
modern Windows and Unix-like systems by default.
To create a USB Gadget in both USB host and USB client mode, you need to load
the kernel module gadgetfs. Here is how to get a running version of
-GadgetFS on a Debian system (see also OpenMoko Wiki5):
The USB CCID Emulator has various command line options to customize the appearance
on the USB host. In order to run the USB CCID Emulator GadgetFS must be loaded
-and mounted. The USB CCID Emulator is compatible with the unix driver libccid3
-and the Windows USB CCID driver4. PIN commands are supported if implemented
+and mounted. The USB CCID Emulator is compatible with the unix driver libccid4
+and the Windows USB CCID driver5. PIN commands are supported if implemented
by the driver.
New in version 0.7: USB CCID Emulator now supports the boxing commands defined in BSI TR-03119
-1.36.
Welcome to PC/SC Relay. The purpose of PC/SC Relay is to relay a smart
card using an contact-less interface. Currently the following contact-less
-emulators are supported:
Command APDUs are received with the contact-less interface and relayed. The
Response APDUs are then sent back via RFID. The contact-less data will be
-relayed to one of the following:
+relayed to one of the following connectors:
to a real smart card inserted into one of the systems’ smart card readers.
The smart card reader must be accessible with PC/SC. The smart card may be
@@ -183,6 +183,20 @@
smart card’s native interface is used and (despite its name) PC/SC Relay
does not need to access PC/SC in this case.
New in version 0.7: We implemented vpcd as user mode device driver for Windows so that
vpicc can directly be used in Windows’ smart card applications that use
PC/SC.
+Virtual Smart Card Reader 11 with a vpcd interface. If you choose
+to download the Windows binaries14, you may directly jump to step 4.
+
In the CI environment, we’re building vpcd for Windows with Visual Studio
+Community 2019 with SDK/WDK for Windows 11. (The WDK version needs to match
+at least your targeted version of Windows, see this guide for installing VS
+with WDK12) The vpcd installer additionally
+requires the WiX Toolset 3.1013 to be installed.
Clone the git repository and make sure it is initialized with all
submodules:
@@ -289,17 +298,31 @@
Building and installing vpcd
If you can successfully Build the solution, you can find
the installer (BixVReaderInstaller.msi) in
virtualsmartcard\win32\BixVReaderInstaller\bin\*Release
-
To install vpcd, double click BixVReaderInstaller.msi. Since we
-are currently not signing the Installer, this will yield a warning about an
-unverified driver software publisher on Windows 8 and later. Click
-Install this driver software anyway.
To import the installer’s test signing certificate, double click
+BixVReader.cer and add it to the Trusted Root Certification
+Authority and the Trusted Publishers at the Local Computer” (not the
+*Current User).
The compiled Windows binaries14 of vpicc include OpenPACE. The other
dependencies listed above need to be installed seperately. You can start the
vpicc via python.exe vicc.py. On all other systems an executable
script vicc is installed using the autotools.
The tool will wait for a (virtual) smart card to appear. Start vpicc and make
+sure to configure it with the correct MRZ, i.e.
+P<UTOERIKSSON<<ANNA<MARIX<<<<<<<<<<<<<<<<<<<L898902C<3UTO6908061F9406236ZE184226B<<<<<14
+in this case:
+
vicc -t ePass
+
+
+
Once the card is connected, cyberflex-shell will quickly perform BAC and
+exit. Running the tool without arguments allows entering in interactive mode
+to run additional tests.
This class implements relaying of a (physical) smartcard. The RelayOS
-forwards the command APDUs received from the vpcd to the real smartcard via
-an actual smart card reader and sends the responses back to the vpcd.
-This class can be used to implement relay or MitM attacks.
The RelayMiddleman class serves as a base from which a user might derive
-their own relay middle man class. This base class implements the simplest
-Man-in-the-Middle: the NoOp.
This method is called on each PDU that is fed into the realy (vdpu -> vicc).
-It may be overwritten to modify the packages send from the terminal to the
-real smart card.
This method is called on each PDU that is produced by the relay (vicc -> vdpu).
-It may be overwritten to modify the packages send from the real smart card to the
-terminal.
Honour the longMessage attribute when generating failure messages.
-If longMessage is False this means:
-* Use only an explicit message if it is provided
-* Otherwise use the standard message for the assert
-
If longMessage is True:
-* Use the standard message
-* If an explicit message is provided, plus ‘ : ‘ and the explicit message
Get a detailed comparison function for the types of the two args.
-
Returns: A callable accepting (first, second, msg=None) that will
-raise a failure exception if first != second with a useful human
-readable error message for those types.
Add a function, with arguments, to be called when the test is
-completed. Functions added are called on a LIFO basis and are
-called after tearDown on test failure or success.
-
Cleanup items are called even if setUp fails (unlike tearDown).
Fail if the two objects are unequal as determined by their
-difference rounded to the given number of decimal places
-(default 7) and comparing to zero, or by comparing that the
-difference between the two objects is more than the given
-delta.
-
Note that decimal places (from zero) are usually not the same
-as significant digits (measured from the most significant digit).
-
If the two objects compare equal then they will automatically
-compare almost equal.
Fail unless a log message of level level or higher is emitted
-on logger_name or its children. If omitted, level defaults to
-INFO and logger defaults to the root logger.
-
This method must be used as a context manager, and will yield
-a recording object with two attributes: output and records.
-At the end of the context manager, the output attribute will
-be a list of the matching formatted log messages and the
-records attribute will be a list of the corresponding LogRecord
-objects.
Fail if the two objects are equal as determined by their
-difference rounded to the given number of decimal places
-(default 7) and comparing to zero, or by comparing that the
-difference between the two objects is less than the given delta.
-
Note that decimal places (from zero) are usually not the same
-as significant digits (measured from the most significant digit).
Fail unless an exception of class expected_exception is raised
-by the callable when invoked with specified positional and
-keyword arguments. If a different type of exception is
-raised, it will not be caught, and the test case will be
-deemed to have suffered an error, exactly as for an
-unexpected exception.
-
If called with the callable and arguments omitted, will return a
-context object used like this:
set1: The first set to compare.
-set2: The second set to compare.
-msg: Optional message to use on failure instead of a list of
-
-
differences.
-
-
-
-
assertSetEqual uses ducktyping to support different types of sets, and
-is optimized for sets specifically (parameters must support a
-difference method).
Fail unless a warning of class warnClass is triggered
-by the callable when invoked with specified positional and
-keyword arguments. If a different type of warning is
-triggered, it will not be handled: depending on the other
-warning filtering rules in effect, it might be silenced, printed
-out, or raised as an exception.
-
If called with the callable and arguments omitted, will return a
-context object used like this:
An optional keyword argument ‘msg’ can be provided when assertWarns
-is used as a context object.
-
The context manager keeps a reference to the first matching
-warning as the ‘warning’ attribute; similarly, the ‘filename’
-and ‘lineno’ attributes give you information about the line
-of Python code from which the warning was triggered.
-This allows you to inspect the warning after the assertion:
Asserts that the message in a triggered warning matches a regexp.
-Basic functioning is similar to assertWarns() with the addition
-that only warnings whose messages also match the regular expression
-are considered successful matches.
-
-
Args:
expected_warning: Warning class expected to be triggered.
-expected_regex: Regex (re.Pattern object or string) expected
-
-
to be found in error message.
-
-
args: Function to be called and extra positional args.
-kwargs: Extra kwargs.
-msg: Optional message used in case of failure. Can only be used
-
-
when assertWarnsRegex is used as a context manager.
Return a context manager that will return the enclosed block
-of code in a subtest identified by the optional message and
-keyword parameters. A failure in the subtest marks the test
-case as failed but resumes execution at the end of the enclosed
-block, allowing further test code to be executed.
Honour the longMessage attribute when generating failure messages.
-If longMessage is False this means:
-* Use only an explicit message if it is provided
-* Otherwise use the standard message for the assert
-
If longMessage is True:
-* Use the standard message
-* If an explicit message is provided, plus ‘ : ‘ and the explicit message
Get a detailed comparison function for the types of the two args.
-
Returns: A callable accepting (first, second, msg=None) that will
-raise a failure exception if first != second with a useful human
-readable error message for those types.
Add a function, with arguments, to be called when the test is
-completed. Functions added are called on a LIFO basis and are
-called after tearDown on test failure or success.
-
Cleanup items are called even if setUp fails (unlike tearDown).
Fail if the two objects are unequal as determined by their
-difference rounded to the given number of decimal places
-(default 7) and comparing to zero, or by comparing that the
-difference between the two objects is more than the given
-delta.
-
Note that decimal places (from zero) are usually not the same
-as significant digits (measured from the most significant digit).
-
If the two objects compare equal then they will automatically
-compare almost equal.
Fail unless a log message of level level or higher is emitted
-on logger_name or its children. If omitted, level defaults to
-INFO and logger defaults to the root logger.
-
This method must be used as a context manager, and will yield
-a recording object with two attributes: output and records.
-At the end of the context manager, the output attribute will
-be a list of the matching formatted log messages and the
-records attribute will be a list of the corresponding LogRecord
-objects.
Fail if the two objects are equal as determined by their
-difference rounded to the given number of decimal places
-(default 7) and comparing to zero, or by comparing that the
-difference between the two objects is less than the given delta.
-
Note that decimal places (from zero) are usually not the same
-as significant digits (measured from the most significant digit).
Fail unless an exception of class expected_exception is raised
-by the callable when invoked with specified positional and
-keyword arguments. If a different type of exception is
-raised, it will not be caught, and the test case will be
-deemed to have suffered an error, exactly as for an
-unexpected exception.
-
If called with the callable and arguments omitted, will return a
-context object used like this:
set1: The first set to compare.
-set2: The second set to compare.
-msg: Optional message to use on failure instead of a list of
-
-
differences.
-
-
-
-
assertSetEqual uses ducktyping to support different types of sets, and
-is optimized for sets specifically (parameters must support a
-difference method).
Fail unless a warning of class warnClass is triggered
-by the callable when invoked with specified positional and
-keyword arguments. If a different type of warning is
-triggered, it will not be handled: depending on the other
-warning filtering rules in effect, it might be silenced, printed
-out, or raised as an exception.
-
If called with the callable and arguments omitted, will return a
-context object used like this:
An optional keyword argument ‘msg’ can be provided when assertWarns
-is used as a context object.
-
The context manager keeps a reference to the first matching
-warning as the ‘warning’ attribute; similarly, the ‘filename’
-and ‘lineno’ attributes give you information about the line
-of Python code from which the warning was triggered.
-This allows you to inspect the warning after the assertion:
Asserts that the message in a triggered warning matches a regexp.
-Basic functioning is similar to assertWarns() with the addition
-that only warnings whose messages also match the regular expression
-are considered successful matches.
-
-
Args:
expected_warning: Warning class expected to be triggered.
-expected_regex: Regex (re.Pattern object or string) expected
-
-
to be found in error message.
-
-
args: Function to be called and extra positional args.
-kwargs: Extra kwargs.
-msg: Optional message used in case of failure. Can only be used
-
-
when assertWarnsRegex is used as a context manager.
Return a context manager that will return the enclosed block
-of code in a subtest identified by the optional message and
-keyword parameters. A failure in the subtest marks the test
-case as failed but resumes execution at the end of the enclosed
-block, allowing further test code to be executed.
Honour the longMessage attribute when generating failure messages.
-If longMessage is False this means:
-* Use only an explicit message if it is provided
-* Otherwise use the standard message for the assert
-
If longMessage is True:
-* Use the standard message
-* If an explicit message is provided, plus ‘ : ‘ and the explicit message
Get a detailed comparison function for the types of the two args.
-
Returns: A callable accepting (first, second, msg=None) that will
-raise a failure exception if first != second with a useful human
-readable error message for those types.
Add a function, with arguments, to be called when the test is
-completed. Functions added are called on a LIFO basis and are
-called after tearDown on test failure or success.
-
Cleanup items are called even if setUp fails (unlike tearDown).
Fail if the two objects are unequal as determined by their
-difference rounded to the given number of decimal places
-(default 7) and comparing to zero, or by comparing that the
-difference between the two objects is more than the given
-delta.
-
Note that decimal places (from zero) are usually not the same
-as significant digits (measured from the most significant digit).
-
If the two objects compare equal then they will automatically
-compare almost equal.
Fail unless a log message of level level or higher is emitted
-on logger_name or its children. If omitted, level defaults to
-INFO and logger defaults to the root logger.
-
This method must be used as a context manager, and will yield
-a recording object with two attributes: output and records.
-At the end of the context manager, the output attribute will
-be a list of the matching formatted log messages and the
-records attribute will be a list of the corresponding LogRecord
-objects.
Fail if the two objects are equal as determined by their
-difference rounded to the given number of decimal places
-(default 7) and comparing to zero, or by comparing that the
-difference between the two objects is less than the given delta.
-
Note that decimal places (from zero) are usually not the same
-as significant digits (measured from the most significant digit).
Fail unless an exception of class expected_exception is raised
-by the callable when invoked with specified positional and
-keyword arguments. If a different type of exception is
-raised, it will not be caught, and the test case will be
-deemed to have suffered an error, exactly as for an
-unexpected exception.
-
If called with the callable and arguments omitted, will return a
-context object used like this:
set1: The first set to compare.
-set2: The second set to compare.
-msg: Optional message to use on failure instead of a list of
-
-
differences.
-
-
-
-
assertSetEqual uses ducktyping to support different types of sets, and
-is optimized for sets specifically (parameters must support a
-difference method).
Fail unless a warning of class warnClass is triggered
-by the callable when invoked with specified positional and
-keyword arguments. If a different type of warning is
-triggered, it will not be handled: depending on the other
-warning filtering rules in effect, it might be silenced, printed
-out, or raised as an exception.
-
If called with the callable and arguments omitted, will return a
-context object used like this:
An optional keyword argument ‘msg’ can be provided when assertWarns
-is used as a context object.
-
The context manager keeps a reference to the first matching
-warning as the ‘warning’ attribute; similarly, the ‘filename’
-and ‘lineno’ attributes give you information about the line
-of Python code from which the warning was triggered.
-This allows you to inspect the warning after the assertion:
Asserts that the message in a triggered warning matches a regexp.
-Basic functioning is similar to assertWarns() with the addition
-that only warnings whose messages also match the regular expression
-are considered successful matches.
-
-
Args:
expected_warning: Warning class expected to be triggered.
-expected_regex: Regex (re.Pattern object or string) expected
-
-
to be found in error message.
-
-
args: Function to be called and extra positional args.
-kwargs: Extra kwargs.
-msg: Optional message used in case of failure. Can only be used
-
-
when assertWarnsRegex is used as a context manager.
Return a context manager that will return the enclosed block
-of code in a subtest identified by the optional message and
-keyword parameters. A failure in the subtest marks the test
-case as failed but resumes execution at the end of the enclosed
-block, allowing further test code to be executed.
Honour the longMessage attribute when generating failure messages.
-If longMessage is False this means:
-* Use only an explicit message if it is provided
-* Otherwise use the standard message for the assert
-
If longMessage is True:
-* Use the standard message
-* If an explicit message is provided, plus ‘ : ‘ and the explicit message
Get a detailed comparison function for the types of the two args.
-
Returns: A callable accepting (first, second, msg=None) that will
-raise a failure exception if first != second with a useful human
-readable error message for those types.
Add a function, with arguments, to be called when the test is
-completed. Functions added are called on a LIFO basis and are
-called after tearDown on test failure or success.
-
Cleanup items are called even if setUp fails (unlike tearDown).
Fail if the two objects are unequal as determined by their
-difference rounded to the given number of decimal places
-(default 7) and comparing to zero, or by comparing that the
-difference between the two objects is more than the given
-delta.
-
Note that decimal places (from zero) are usually not the same
-as significant digits (measured from the most significant digit).
-
If the two objects compare equal then they will automatically
-compare almost equal.
Fail unless a log message of level level or higher is emitted
-on logger_name or its children. If omitted, level defaults to
-INFO and logger defaults to the root logger.
-
This method must be used as a context manager, and will yield
-a recording object with two attributes: output and records.
-At the end of the context manager, the output attribute will
-be a list of the matching formatted log messages and the
-records attribute will be a list of the corresponding LogRecord
-objects.
Fail if the two objects are equal as determined by their
-difference rounded to the given number of decimal places
-(default 7) and comparing to zero, or by comparing that the
-difference between the two objects is less than the given delta.
-
Note that decimal places (from zero) are usually not the same
-as significant digits (measured from the most significant digit).
Fail unless an exception of class expected_exception is raised
-by the callable when invoked with specified positional and
-keyword arguments. If a different type of exception is
-raised, it will not be caught, and the test case will be
-deemed to have suffered an error, exactly as for an
-unexpected exception.
-
If called with the callable and arguments omitted, will return a
-context object used like this:
set1: The first set to compare.
-set2: The second set to compare.
-msg: Optional message to use on failure instead of a list of
-
-
differences.
-
-
-
-
assertSetEqual uses ducktyping to support different types of sets, and
-is optimized for sets specifically (parameters must support a
-difference method).
Fail unless a warning of class warnClass is triggered
-by the callable when invoked with specified positional and
-keyword arguments. If a different type of warning is
-triggered, it will not be handled: depending on the other
-warning filtering rules in effect, it might be silenced, printed
-out, or raised as an exception.
-
If called with the callable and arguments omitted, will return a
-context object used like this:
An optional keyword argument ‘msg’ can be provided when assertWarns
-is used as a context object.
-
The context manager keeps a reference to the first matching
-warning as the ‘warning’ attribute; similarly, the ‘filename’
-and ‘lineno’ attributes give you information about the line
-of Python code from which the warning was triggered.
-This allows you to inspect the warning after the assertion:
Asserts that the message in a triggered warning matches a regexp.
-Basic functioning is similar to assertWarns() with the addition
-that only warnings whose messages also match the regular expression
-are considered successful matches.
-
-
Args:
expected_warning: Warning class expected to be triggered.
-expected_regex: Regex (re.Pattern object or string) expected
-
-
to be found in error message.
-
-
args: Function to be called and extra positional args.
-kwargs: Extra kwargs.
-msg: Optional message used in case of failure. Can only be used
-
-
when assertWarnsRegex is used as a context manager.
Return a context manager that will return the enclosed block
-of code in a subtest identified by the optional message and
-keyword parameters. A failure in the subtest marks the test
-case as failed but resumes execution at the end of the enclosed
-block, allowing further test code to be executed.
Honour the longMessage attribute when generating failure messages.
-If longMessage is False this means:
-* Use only an explicit message if it is provided
-* Otherwise use the standard message for the assert
-
If longMessage is True:
-* Use the standard message
-* If an explicit message is provided, plus ‘ : ‘ and the explicit message
Get a detailed comparison function for the types of the two args.
-
Returns: A callable accepting (first, second, msg=None) that will
-raise a failure exception if first != second with a useful human
-readable error message for those types.
Add a function, with arguments, to be called when the test is
-completed. Functions added are called on a LIFO basis and are
-called after tearDown on test failure or success.
-
Cleanup items are called even if setUp fails (unlike tearDown).
Fail if the two objects are unequal as determined by their
-difference rounded to the given number of decimal places
-(default 7) and comparing to zero, or by comparing that the
-difference between the two objects is more than the given
-delta.
-
Note that decimal places (from zero) are usually not the same
-as significant digits (measured from the most significant digit).
-
If the two objects compare equal then they will automatically
-compare almost equal.
Fail unless a log message of level level or higher is emitted
-on logger_name or its children. If omitted, level defaults to
-INFO and logger defaults to the root logger.
-
This method must be used as a context manager, and will yield
-a recording object with two attributes: output and records.
-At the end of the context manager, the output attribute will
-be a list of the matching formatted log messages and the
-records attribute will be a list of the corresponding LogRecord
-objects.
Fail if the two objects are equal as determined by their
-difference rounded to the given number of decimal places
-(default 7) and comparing to zero, or by comparing that the
-difference between the two objects is less than the given delta.
-
Note that decimal places (from zero) are usually not the same
-as significant digits (measured from the most significant digit).
Fail unless an exception of class expected_exception is raised
-by the callable when invoked with specified positional and
-keyword arguments. If a different type of exception is
-raised, it will not be caught, and the test case will be
-deemed to have suffered an error, exactly as for an
-unexpected exception.
-
If called with the callable and arguments omitted, will return a
-context object used like this:
set1: The first set to compare.
-set2: The second set to compare.
-msg: Optional message to use on failure instead of a list of
-
-
differences.
-
-
-
-
assertSetEqual uses ducktyping to support different types of sets, and
-is optimized for sets specifically (parameters must support a
-difference method).
Fail unless a warning of class warnClass is triggered
-by the callable when invoked with specified positional and
-keyword arguments. If a different type of warning is
-triggered, it will not be handled: depending on the other
-warning filtering rules in effect, it might be silenced, printed
-out, or raised as an exception.
-
If called with the callable and arguments omitted, will return a
-context object used like this:
An optional keyword argument ‘msg’ can be provided when assertWarns
-is used as a context object.
-
The context manager keeps a reference to the first matching
-warning as the ‘warning’ attribute; similarly, the ‘filename’
-and ‘lineno’ attributes give you information about the line
-of Python code from which the warning was triggered.
-This allows you to inspect the warning after the assertion:
Asserts that the message in a triggered warning matches a regexp.
-Basic functioning is similar to assertWarns() with the addition
-that only warnings whose messages also match the regular expression
-are considered successful matches.
-
-
Args:
expected_warning: Warning class expected to be triggered.
-expected_regex: Regex (re.Pattern object or string) expected
-
-
to be found in error message.
-
-
args: Function to be called and extra positional args.
-kwargs: Extra kwargs.
-msg: Optional message used in case of failure. Can only be used
-
-
when assertWarnsRegex is used as a context manager.
Return a context manager that will return the enclosed block
-of code in a subtest identified by the optional message and
-keyword parameters. A failure in the subtest marks the test
-case as failed but resumes execution at the end of the enclosed
-block, allowing further test code to be executed.
Honour the longMessage attribute when generating failure messages.
-If longMessage is False this means:
-* Use only an explicit message if it is provided
-* Otherwise use the standard message for the assert
-
If longMessage is True:
-* Use the standard message
-* If an explicit message is provided, plus ‘ : ‘ and the explicit message
Get a detailed comparison function for the types of the two args.
-
Returns: A callable accepting (first, second, msg=None) that will
-raise a failure exception if first != second with a useful human
-readable error message for those types.
Add a function, with arguments, to be called when the test is
-completed. Functions added are called on a LIFO basis and are
-called after tearDown on test failure or success.
-
Cleanup items are called even if setUp fails (unlike tearDown).
Fail if the two objects are unequal as determined by their
-difference rounded to the given number of decimal places
-(default 7) and comparing to zero, or by comparing that the
-difference between the two objects is more than the given
-delta.
-
Note that decimal places (from zero) are usually not the same
-as significant digits (measured from the most significant digit).
-
If the two objects compare equal then they will automatically
-compare almost equal.
Fail unless a log message of level level or higher is emitted
-on logger_name or its children. If omitted, level defaults to
-INFO and logger defaults to the root logger.
-
This method must be used as a context manager, and will yield
-a recording object with two attributes: output and records.
-At the end of the context manager, the output attribute will
-be a list of the matching formatted log messages and the
-records attribute will be a list of the corresponding LogRecord
-objects.
Fail if the two objects are equal as determined by their
-difference rounded to the given number of decimal places
-(default 7) and comparing to zero, or by comparing that the
-difference between the two objects is less than the given delta.
-
Note that decimal places (from zero) are usually not the same
-as significant digits (measured from the most significant digit).
Fail unless an exception of class expected_exception is raised
-by the callable when invoked with specified positional and
-keyword arguments. If a different type of exception is
-raised, it will not be caught, and the test case will be
-deemed to have suffered an error, exactly as for an
-unexpected exception.
-
If called with the callable and arguments omitted, will return a
-context object used like this:
set1: The first set to compare.
-set2: The second set to compare.
-msg: Optional message to use on failure instead of a list of
-
-
differences.
-
-
-
-
assertSetEqual uses ducktyping to support different types of sets, and
-is optimized for sets specifically (parameters must support a
-difference method).
Fail unless a warning of class warnClass is triggered
-by the callable when invoked with specified positional and
-keyword arguments. If a different type of warning is
-triggered, it will not be handled: depending on the other
-warning filtering rules in effect, it might be silenced, printed
-out, or raised as an exception.
-
If called with the callable and arguments omitted, will return a
-context object used like this:
An optional keyword argument ‘msg’ can be provided when assertWarns
-is used as a context object.
-
The context manager keeps a reference to the first matching
-warning as the ‘warning’ attribute; similarly, the ‘filename’
-and ‘lineno’ attributes give you information about the line
-of Python code from which the warning was triggered.
-This allows you to inspect the warning after the assertion:
Asserts that the message in a triggered warning matches a regexp.
-Basic functioning is similar to assertWarns() with the addition
-that only warnings whose messages also match the regular expression
-are considered successful matches.
-
-
Args:
expected_warning: Warning class expected to be triggered.
-expected_regex: Regex (re.Pattern object or string) expected
-
-
to be found in error message.
-
-
args: Function to be called and extra positional args.
-kwargs: Extra kwargs.
-msg: Optional message used in case of failure. Can only be used
-
-
when assertWarnsRegex is used as a context manager.
Return a context manager that will return the enclosed block
-of code in a subtest identified by the optional message and
-keyword parameters. A failure in the subtest marks the test
-case as failed but resumes execution at the end of the enclosed
-block, allowing further test code to be executed.