Sparkasse Chemnitz decided that PIN/iTAN based authentication for bank transactions are obsolete. The new methods which are currently advertised as the "more secure alternatives" are chipTAN and smsTAN. Both are not known for their strong security and vendor specific implementations seemed to be even worse. The only acceptable solution for me is HBCI/FinTS using chipcards and a decent smart card reader with pinpad. At least this method was not yet dropped by them and I still hope that my application for it will be granted after 13 years (August 23 will be the anniversary).
I've decided to test a ReinerSCT cyberJack and use it together with KMyMoney. At least the AqBanking integration of KMyMoney provided a good support for PIN/TAN based import of transactions and should be even better for chipcard access through PC/SC. The best part seems to be the opensource userspace driver for Linux which can be downloaded from the official webpage and is still maintained. Ubuntu Wiki also provides a guide for the installation. Unfortunately, the guide is outdated and the binary distribution doesn't seem to work on a recent Debian sid system. It is still possible to get everything to work as expected.
The most important part is to install KMyMoney with the AqBanking HBCI integration in libaqbanking*-plugins and the support for chipcards through libchipcard-libgwenhywfar*-plugins. A PC/SC daemon called pcscd and the actual ReinerSCT must also be prepared. The latter one needs to be compiled by us and installed system-wide using dpkg. It is highly recommended to have pbuilder or cowbuilder configured to create the Debian packages. It is easier and cleaner than building it with debuild and installing all dependency by hand on the actual system.
$ apt-get install usbutils kmymoney pcscd dpkg-dev libaqbanking33-plugins libchipcard-libgwenhywfar60-plugins $ lsusb |grep Reiner Bus 001 Device 003: ID 0c4b:0300 Reiner SCT Kartensysteme GmbH cyberJack pinpad(a)
The source code of the cyberjack Debian packages is slightly outdated and cannot be build on current system. The newest version was 3.99.5_SP02 from 2011-06-14. Only smaller modifications have to be made to fix the build failures. The pbuilder can create the Debian binary packages after we supplied him with the fixed Debian source package.
$ wget http://support.reiner-sct.de/downloads/LINUX/V3.99.5_SP02/pcsc-cyberjack_3.99.5final.SP02.tar.gz $ tar xfz pcsc-cyberjack_3.99.5final.SP02.tar.gz $ patch -d pcsc-cyberjack-3.99.5final.SP02 -p1 -i ../20110806-0-pcsc-cyberjack.patch patching file debian/control patching file debian/rules patching file ifd/ifd.cpp $ dpkg-source -b pcsc-cyberjack-3.99.5final.SP02 dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1) dpkg-source: info: using source format `1.0' dpkg-source: info: building pcsc-cyberjack in pcsc-cyberjack_3.99.5final.SP02.tar.gz dpkg-source: info: building pcsc-cyberjack in pcsc-cyberjack_3.99.5final.SP02.dsc $ cowbuilder --build pcsc-cyberjack_3.99.5final.SP02.dsc --buildresult pscs-cyperjack_debs/ ....
Some special packages have to be installed before the .deb files can be used. The tool killall from psmisc must be available or the postinst script of libifd-cyberjack6 will fail. The hal package is required to enable the detection of supported devices in the cyberjack integration. The functionality can be tested by running either the console application cyberjack or the graphical interface fxcyberjack.
$ apt-get install psmisc hal
$ dpkg -i pscs-cyperjack_debs/*.deb
$ apt-get install -f
$ cyberjack
BEGIN: ermittle Distribution (0/5)
END : ermittle Distribution (1/5) [OK]
BEGIN: ermittle Systeminformationen (1/5)
END : ermittle Systeminformationen (2/5) [OK]
BEGIN: ermittle Gruppeninformation (2/5)
END : ermittle Gruppeninformation (3/5) [ERROR]
BEGIN: ermittle laufende Dienste (3/5)
END : ermittle laufende Dienste (4/5) [OK]
BEGIN: ermittle und teste angeschlossene Leser (4/5)
END : ermittle und teste angeschlossene Leser (5/5) [OK]
Es wurden 3 Dateien im aktuellen Verzeichnis angelegt:
- cyberjack-report.log: Enthaelt die Ergebnisse der Tests
- cyberjack-hints.log : Enthaelt moeglicherweise Hinweise
zu gefundenen Problemen und deren
Behebung.
- cyberjack.xml : Enthaelt die Testergebnisse in fuer
den Support aufbereiteter Form.
Bitte senden Sie bei Problemen die Datei "cyberjack.xml"
an den Linux-Support von Reiner SCT.
$ fxcyberjack
The cyberjack tool correctly recognized that there is no group called cyberjack and normal users have to be part of that group to use the card reader. Also a udev rule has to be added to set the access rights of the device correctly.
$ groupadd cyberjack
$ adduser sven cyberjack
$ echo 'ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0c4b", GROUP="cyberjack", MODE="660"' > \
/etc/udev/rules.d/z80_cyberjack.rules
The AqBanking integration can now be configured in KMyMoney through "Tools" - "Configure AqBanking". It is important to create the "aqhcbi" account before trying to use anything related to "User account" (there seems to be a small bug which causes an assertion to fail).
as we started to have different branches and repositories, everything became a little bit more complex to track. I will try to summarize what and where is something going on inside the batman-adv universe.
There is currently one main change happening in the branch design. The branch currently called 'maint' will be renamed to 'next'. This should reflect that we work there on the features (already part of master/trunk) which should be submitted to the kernel maintainers. This branch is stopped quite early in the development phase - even before the kernel with the corresponding features will be released.
For example the current patches for linux 2.6.36 (which will may be released in 5 weeks) will be finished with the release of v2010.1.0. The next branch will get immediately all patches which will be part of linux 2.6.37. This is needed because all patches must be tested in linux-next a long time before Linus Torvalds opens the merge window vor linux 2.6.37.
Of course, this will create a small gap for bug fixes which will enter linux 2.6.36 after the release of v2010.1.0. That's why we now use the maint branch to track those changes. Maint will always be a branch on top of the last release with all bugfixes which must be added to that release and are not features for the next branch.
That new maint branch will also help other distributors to easily find patches which should be applied on top of their shipped versions or for users which want to build their version of batman-adv manually and still get a version which fixes (hopefully) all know bugs. And maybe we will have bug fix releases in the future...
In trunk is always summer - so changes always(?) enter here and will get moved to other branches unless they need some more time to get a fine flavor - or at least more testing. Even if everything should hit trunk, it is easier to describe changes in a different places (next, master-rebase).
This branch can be used together with trunk/batctl/
This is were commits are gathered to be send later to the linux kernel folks. Only tested features or features which are dependencies for the in-kernel batman-adv should enter this branch.
Since the last time many things happened, but not all are finished yet. So for example the release of v2010.1.0 is still pending and so no patches for linux-2.6.37 have been send to GregKH.
Meanwhile we had to deal a little bit with some regressions which were added when we changed to everything from procfs to sysfs. This is the reason why there were some patches sent to the linux stable-tree folks lately.
After that release we we will merge some patches which are mostly needed to push the merge of batman-adv into linux-net a little bit further. That includes for example the preparation of nearly all data inside of skbs instead of external buffers and the usage of optimized kernel functionality for things which we tried to implement ourself. But of course there are again quite interesting features:
Also patches were added which tweaked a little bit here and there. Many of them came directly from the kernel folks and dealt with smaller coding style problems.
This branch can be used together with batctl-next
The release of linux 2.6.36 isn't finished yet, but we have submitted all patches in next. We aren't yet in net/, but hope that this follows soon. All problems which David S. Miller found were relative small and already fixed. We will wait until the first patches for the upcoming merge window were send to the staging tree, before we try to get really into net/.
You may experienced some weird regressions when using early -RCs of linux 2.6.36. Those happened due to some smaller patch war between the guys from linux-net and us. Those changes clashed when GregKH had to merge them after the release of 2.6.35. Unfortunately he resolved the merge conflicts a little bit different than I expected. But those problems should be solved with the upcoming release of linux 2.6.36-rc3.
The dirty place were all the linux integration happens. It is ugly, misunderstood and uninteresting for most people.
The last synchronization point was GregKH-20100821. It is a merge of linux-2.6.36-rc1 and v2010.0.0-46-ge3a0cc9 + a documentation of all files we create in sysfs. So this synchronization point (a git tag) just says that we checked at least linux-2.6.36-rc1 for new patches not yet integrated in next/trunk of batman-adv and that we send our changes until that point to GregKH.
My personal playground. (With a little delay) I will try to get all changes in trunk rebased on top of next. As result we get only the essence of changes in trunk which aren't already part of next. This also means for example that patches will look like they were made with sysfs in mind when they are originally created files in /proc. Even when I always ensure that the files in master and rebase are 100% equal, the original author may not be blamed when a single patch will try to eat your pet (or you could say that patches in that branch will not be checked by their original authors and I will only guarantee that when you apply all patches you will get the same files as in trunk).
Nevertheless it is a great place to get and test feature patches on top of next without using the complete set of changes in master. Or to understand what goes on in trunk compared to next.
After the release of v2010.1.0 we will only have the gateway patches again waiting to get merged into next.
This branch will jump around and it is not save to track it using a local git branch.
This branch can be used together with trunk/batctl/
Maybe this is a good place to announce that there is something like master-rebase also to rebase current patches of batctl on top of the latest release. It is unknown who will continue the work on that, but as it is not as complex at the kernel module, I doubt that it is really much work rebase and reorder those patches.
as we started to have different branches and repositories, everything became a little bit more complex to track. I will try to summarize what and where is something going on inside the batman-adv universe.
Please note that the different repositories and branches were changed slightly. For example batctl is now also available using git and the linux integration branch was moved to a separate repository.
In trunk is always summer - so changes always(?) enter here and will get moved to other branches unless they need some more time to get a fine flavor - or at least more testing. Even if everything should hit trunk, it is easier to describe changes in a different places (maint, master-rebase).
This branch can be used together with trunk/batctl/
This is were commits are gathered to be send later to the linux kernel folks. Only tested features or features which are dependencies for the in-kernel batman-adv should enter this branch.
Since the last time a lot of things happen. The most important one is probably the release of batman-adv 2010.0.0. This is essentially what you will get when you will build linux 2.6.35 - or what you will get when Linus will come back from his vacation and merges GregKH's staging branch.
Since that release we merged some patches from master which seems to work good enough (at least no major flaw was found during WMBv3).
Also smaller patches entered it. For example some java style namings of variables and functions were converted to better match the kernel coding style, rounding issues were identified + resolved and the code was cleaned up a little bit.
This branch can be used together with batctl-maint
The release of linux 2.6.35 isn't finished yet, but we have submitted all patches in maint. This means that we have hopefully all patches in 2.6.36 we wanted - this includes the debugfs and netfilter patches which were dropped in 2.6.35 because they were submitted to late (during the 2.6.35 merge window instead a week before 2.6.34 was released).
We also tried to contact the network subsystem developers to get a review for batman-adv. This is needed to get it moved from drivers/staging/batman-adv to net/batman-adv/. Even if our goal is not to get it merged in 2.6.36, we still hope that we get enough information to merge soon into net/.
This branch was removed after the release of batman-adv 2010.0.0.
The dirty place were all the linux integration happens. It is ugly, misunderstood and uninteresting for most people.
The last synchronization point was GregKH-20100625. It is a merge of v2.6.34 and v2010.0.0-30-g13bc17e + a documentation of all files we create in sysfs. So this synchronization point (a git tag) just says that we check at least v2.6.34 for new patches not yet integrated in maint/trunk of batman-adv and that we send our changes until that point to GregKH.
My personal playground. (With a little delay) I will try to get all changes in trunk rebased on top of maint. As result we get only the essence of changes in trunk which aren't already part of maint. This also means for example that patches will look like they were made with sysfs in mind when they are originally created files in /proc. Even when I always ensure that the files in master and rebase are 100% equal, the original author may not be blamed when a single patch will try to eat your pet (or you could say that patches in that branch will not be checked by their original authors and I will only guarantee that when you apply all patches you will get the same files as in trunk).
Nevertheless it is a great place to get and test feature patches on top of maint without using the complete set of changes in master. Or to understand what goes on in trunk compared to maint.
Currently we have following patches waiting inside of it
This branch will jump around and it is not save to track it using a local git branch.
This branch can be used together with trunk/batctl/
as we started to have different branches and repositories, everything became a little bit more complex to track. I will try to summarize what and where is something going on inside the batman-adv universe.
In trunk is always summer - so changes always(?) enter here and will get moved to other branches unless they need some more time to get a fine flavor - or at least more testing. Even if everything should hit trunk, it is easier to describe changes in a different place.
This branch can be used together with trunk/batctl/
This is were commits are gathered to be send later to the linux kernel folks. Only tested features or features which are dependencies for the in-kernel batman-adv should enter this branch. We have already created the release v0.2.1 only from commits inside that branch while we developed new features in trunk.
Since that release we received smaller patches which were merged into the linux mainline first or which were send to us directly from people which actually wanted to fix problems of the in-kernel batman-adv directly. We had for example style changes or patches which will guarantee that batman-adv still builds in upcoming kernel releases - things we otherwise would have to analyse after that kernel was released. So instead of having a user which notices that batman-adv doesn't build anymore, we got the fix for the problem which will exist somewhere in the future directly from the people which will create that problem. :)
As one of the bigger changes we started to port batman-adv from /proc to sysfs and debugfs. batctl was also changed to work on top of the new configuration and debugging infrastructure. Unfortunately this change is a two step process. First we changed everything from /proc to sysfs and later moved parts of the files in sysfs to debugfs because they were not single value files. But later more about those changes in maint-0.2.2.
Beside smaller bugfixes, a bigger problem was found when receiving an enormous amount of broadcast packets which must be rebroadcasted. It could happen that those packets looped inside the mesh. It was tried to fix that problem without changing the packet format. Even if that reduced the problem, there are more changes coming later which needs changes to the packet format.
Also a smaller new feature has entered maint - the ability to allow netfilter/ebtables to filter incoming packets which are directly for batman-adv.
This branch can be used together with branches/batctl-0.2.x/
The merge window has opened over a week ago and all patches (patches we send at least a week before it was opened) were accepted. Newer bugfixes will probably accepted in some days. Unfortunately some patches like the move of some files to debugfs weren't finished right in time and will only be merged into linux-2.6.36 because they are more than just simple bugfixes. That includes the removing of /dev/batman-adv in favor of debugfs, moving of tables from sysfs to debugfs and the netfilter integration.
As we weren't able to merge all patches inside maint in linux-2.6.35 and we still want to be able to provide a release which behaves like the version in 2.6.35, it was decided that we just use a version before the debugfs patches and create a branch which will gather all bugfixes in maint. It will be merged and removed after the release of batman-adv-kernelland-0.2.2 or plans are changed. So better don't start a friendship with this little buddy.
If you want to try that branch or any snapshot of 2.6.35 then please try revision r1664 of branches/batctl-0.2.x/
The dirty place were all the linux integration happens. It is ugly, misunderstood and uninteresting for most people.
The last synchronization point was GregKH-20100522. It is a merge of v2.6.34 and v0.2.1-38-gbcde864 + a documentation of all files we create in sysfs. So this synchronization point (a git tag) just says that we check at least v2.6.34 for new patches not yet integrated in maint/trunk of batman-adv and that we send our changes until that point to GregKH.
In reality the patches are modified a little bit.
All those changes are done for each patch (or at least ensured that no changes will conflict with those points) on top of the last merge point. This should ensure that we don't diverge too much from maint with the in-kernel batman-adv.
Each patch is then applied on top of a current linux-next, tested if it compiles, checked with sparse and checkpatch.pl --strict. When everything looks fine, they get exported again using git-format-patch and send to GregKH.
Only because a change is part of a synchronization point, it doesn't mean that it will appear with the next linux kernel. As said before, all bugfixes between GregKH-20100510 and GregKH-20100522 will be part of 2.6.35, but anything bigger will be part of 2.6.36.
My personal playground. (With a little delay) I will try to get all changes in trunk rebased on top of maint. As result we get only the essence of changes in trunk which aren't already part of maint. This also means for example that patches will look like they were made with sysfs in mind even when they are originally created files in /proc. Even when I always ensure that the files in master and rebase are 100% equal, the original author may not be blamed when a single patch will try to eat your pet (or you could say that patches in that branch will not be checked by their original authors and I will only guarantee that when you apply all patches you will get the same files as in trunk).
Nevertheless it is a great place to get and test feature patches on top of maint without using the complete set of changes in master. Or to understand what goes on in trunk compared to maint.
Of course you cannot use all patches in any order because they have dependencies between each other. A the moment we have following patches which should be quite easy to use together with any other patch:
We have also patches which changes the packet compat version to 9 (all gateway patches must be used in that order, otherwise they would not apply):
The last patch increases the compat version 10 and thus requires the patches which justify the compat version 9 ("adding gateway functionality", "record route for ICMP messages"):
This branch will jump around and it is not save to track it using a local git branch.
This branch can be used together with trunk/batctl/
mupen64plus has changed its internal structure slightly with its upcoming release featuring the new API 2.0. Beside the most obvious change for the user - the removal of a graphical interface as part of the core distribution, there will be an explosion of packages provided by debian.
Currently we provide one package for mupen64plus which includes everything to emulate a N64 and another one which includes only the debugging symbols (a package I always wanted to remove in favor of the planned .ddebs). In the future the mupen64plus package will still be there, but only to provide a meta packages which depends either on a single ui or all available uis for the core library. But since the only usable ui at the moment is mupen64plus-ui-console, the difference will not be really important to the user. We will probably see mupen64plus recommend utilities in the future for savestate conversation or similar tools, but not right now. So this package can be compared to the xorg meta package.
Each ui has now to load the core library (current package name is libmupen64plus2). In contrast to most other libraries, it isn't meant to be loaded implicit by the DT_NEEDED entries in the elf binaries, but by the ui directly through dlopen. This means that we can have different version of the library available on the system for different purposes (profiling, debugging, speed optimized emulation, core comparison, ...) and the user can switch between these library using ui functionality. As most of these will be only rare and special versions used by persons which work on the core, I will provide only one version of the core at the moment - maybe add another one when there is really need for it, but for now the ui has simply to depend on libmupen64plus2.
Because each each ui has also the full control which plugins it loads, the ui package will also depend on plugins and not let the mupen64plus or the libmupen64plus2 package do that job. For each type (rsp, input, audio, video) the user has to provide at least one plugin. For easier usage it will be possible to select a mupen64-*-all package which depends on all package of a type which were known till the upload of the package. But it isn't necessary to install all - a single package for each type which provides a specific virtual package (mupen64plus-rsp-1, mupen64plus-input-1, mupen64plus-audo-1, mupen64plus-video-1) is enough to fulfill the dependencies of mupen64plus-ui-console - how future ui packages have to handle this is unknown, but hopefully the same way as the console ui does it.
Plugins in debian will be for now:
The *-z64 plugins can only be used together. So if you want to use them
please check that you start the emulator with
mupen64plus --rsp mupen64plus-rsp-z64 --gfx mupen64plus-video-z64
If anyone wants to start to work a little bit with the packages: They can be cloned easily with gbp-clone from git-buildpackage:
for i in audio-sdl core input-sdl rsp-hle rsp-z64 ui-console video-arachnoid video-glide64 video-rice video-z64; do
gbp-clone --pristine-tar git://git.debian.org/git/collab-maint/mupen64plus-$i.git
doneYou will not be able to build these package for anything else then (linux|kfreebsd)-amd64 or (linux|kfreebsd)-i386. If you want to work on better platform support then please get in contact with upstream. There are also works available for armel (pandora) and powerpc (gamecube/wii). But since patches for these changes weren't provided for the mupen64plus developers, these platforms cannot be supported at the moment.
Btw. the input plugin has now a auto-configuration. To add your own gamepad/joystick supported, please send a mail with your old ~/.config/mupen64plus/blight_input.conf to the maintainers.
After different people requested that I take notes on my "chili year 2010". This year I will only plant two different types - Habanero and Cayenne. Both types of seeds aren't from a special seeds supplier, so I will not try to say what exact type of Habanero it is.
| date | action/situation |
|---|---|
| 2010-01-23 |
|
| 2010-01-25 |
|
| 2010-02-01 |
|
| 2010-02-18 |
|
| 2010-04-17 |
|
| 2010-05-22 |
|
| 2010-06-19 |
|
| 2010-06-26 |
|
| 2010-07-12 |
|
| 2010-08-21 |
|
After the decision to remove linux-modules-extra-2.6 from Debian, it is now time to move all modules to a new method for compilation. Nothing is bad about module-assistant - beside the problem that you must know about it and understand how to use it.
Dynamic Kernel Module Support provides a simple solution for the end user as
it will handle recompilation after a new installation of a kernel or a new module. The user only have
to provide the kbuild for his current kernel and DKMS will to the remaining magic. In a normal situation DKMS should
recommend to install the headers and makes it unnecessary for the user to install it manually. This means that
headers should be available for dkms unless the user thinks different. If the user has compiled his own kernel he must
ensure that /lib/modules/`uname -r`/build points to a valid build environment for the running kernel.
batman-adv-kernelland and batmand provide the modules batman-adv-dkms and batmand-gateway-dkms in addition to batman-adv-source and batmand-gateway-source. This was done to ensure that the user is in full control over the way he wants to build his modules - even if this means that he wants to build some modules with modules-assistant and some with dkms. It is different to the way Ubuntu is doing it at the moment, but there is no real Debian Policy or recommentation how to handle it until now. Only small examples were given how to write packages which supports DKMS.
It should also fix the problem that the version of my batman-adv-source package is nearly all the time newer then the binary package created by linux-modules-extra-2.6, but apt(itude) still wants to update to it instead of using the module created using module-assistant. A smaller glitch which got me some "bug reports" over private channels.
Lets hope that more packages (only three until now) will move on to dkms soon. It is only a matter of time before the bug #552369 is closed and all binary free extra modules will disappear from the archives. linux-modules-nonfree-2.6 was already removed, but there is currently no real reactions for the related bugs.
mupen64plus was accepted by ftp-masters and will hit the archives soon. The debian package needed some adjustments to be accepted. This means that glN64 had to be removed because it is not distributed under a dfsg compliant license. If anyone knows Orkin then please ask him to contact the mupen64plus team.
All other changes shouldn't be that visible for users. Some bugs were fixed and some libraries were stripped from the build process and replaced by official packaged ones. It builds on many different architectures, but as x86 and amd64 are the only supported architectures by upstream the experience will differ.
Upcoming stuff for debian are:
Upstream is also starting a big rewrite to seperate gui from the rest (so no more gtk/qt specific stuff inside plugins), make most of the code platform independent and splitting everything to be more modular. Also some low level plugins are currently developed inside their trunk. So it looks quite promising for the future. But please don't ask to package the qt gui before the rewrite has been merged.
Before I forget it: Congratulations to Tobias for your first package in Debian (and in Ubuntu Universe after their sync with debian).
