akaro / persoapp Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/persoapp
Automatically exported from code.google.com/p/persoapp
Thanks,
Christian
Original issue reported on code.google.com by [email protected]
on 8 Jul 2013 at 2:17
What steps will reproduce the problem?
1. try to use ePA in free software applications
2. consider the fact that you want to give the code everything needed to run it
to end-users
3. consider that you cannot certify each end user separately as trusted to
extract his private data from his nPA, and that you don't want to do this as a
test but for a real-world application.
What is the expected output? What do you see instead?
Successful free software deployment without SaaSS (no typo). This requires an
ePA function that has no bad privacy implications when used by "anybody".
Creating a pseudonym to defeat Sybil attacks in overlay networks fits this
category nicely. What I would like to see is an API/example to do exactly this,
and a business process to freely generate the necessary certificates to allow
_anyone_ to create pseudonyms for "any" application free of charge (while
strictly limiting the number of pseudonyms created per individual per
application to one).
What version of the product are you using? On what operating system?
n/a. GNU operating systems.
Please provide any additional information below.
For free software to be able to use PersoApp in realistic 'libre' deployments
(where it is not just used as part of a service), the certification process is
a major roadblock, not just because of the expense but because there is no
organization to be certified or to hold the private key. I understand that the
process is supposed to safeguard private information. Still, there is possibly
one exception to this: the pseudonym function.
One big security issue in P2P networks is the so-called "Sybil" attack, where
an adversary creates many identities (let's wildly assume the adversary does
not control the Bundesdruckerrei this time). This could be prevented if each
user had to show that he was 'real', by creating an unlinkable,
application-specific pseudonym using the ePA. As merely creating a pseudonym
--- which should not be linkable to any 'real' identity or any personal data of
the ePA, or any other pseudonym created for any other application --- is NOT
private data (it's just a capability), this would be a useful way to defeat
Sybil attacks (I would want this for my GNU project) AND I see no technical
and/or privacy reasons why certificates that would allow applications to use
this function could not be created cheaply (i.e. for free, as it can be done
without any kind of audit), and without certifying a formal organization (which
often does not exist for free software projects).
Ultimately, I would like to have a (simple) API to obtain a pseudonym for a
given application identifier, i.e. I might specify "GNUnet" as the application
identifier, and if there is a valid ePA in the device (and the user authorizes
the operation, depending on reader, etc.) the API returns a pseudonym (ideally
a private key that I can use for signatures, where the corresponding public key
is certified to be a valid pseudonym that corresponds to a real human by
"Germany"). Now, that's the ideal, but of course going to some website, typing
in some application identifier ("GNUnet") and (automatically, without a fee)
receiving a Berechtigungszertifikat first which would then be passed to the
reader by the application later would also be acceptable.
Note that saying "but you can do everything in the Test-DV" without needing
formal certification is not helpful at all --- eventually, a free software
project wants to be used by real users in the real world, and at that point I
must give the private key to obtain the information to each user, and I want it
to work with real ePAs, not fake test crap. So as long as real-world
deployment is prevented, why would I bother to develop something for the
Test-DV? This is why this proposal is important: it could be deployed to the
real world in free software without creating privacy issues.
Original issue reported on code.google.com by [email protected]
on 31 Jan 2014 at 7:06
Problem:
Nach dem SVN Checkout befindet sich unter /libs/build_repackaged.jar eine
deutlich ältere Version der PersoApp-Core als unter
/mvn-repo/de/persoapp/persoapp-core/persoapp-core-1.0.1.jar.
Obwohl die Version persoapp-core-1.0.1.jar im Gradle-Build-Script verarbeitet
wird, wird sie nicht berücksichtigt. Die APK wird immer mit der älteren
Core-Version aus /libs/build_repackaged.jar gebaut.
What steps will reproduce the problem?
- SVN Checkout und Build.
What version of the product are you using? On what operating system?
- SVN Versionen 140-146
Please provide any additional information below.
Um mit unserem eID-Testserver der mtg zu kommunizieren, mussten wir Änderungen
am Core der PersoApp vornehmen. Dieser veränderte Core sollte anschließend
neben der PersoApp-Desktop auch in der Android Version verwendet werden.
Das Gradle-Build Script der Android Version hat unsere Version des Cores auch
ohne Probleme verarbeitet. Wir konnten anschließend allerdings nicht
feststellen, dass die von uns vorgenommenen Änderungen auch in der fertigen
.apk vorhanden sind.
Der Ordner /libs enthält nur die "build_repackaged.jar". Diese haben wir uns
genauer angeschaut und festgestellt, dass die verwendeten .class Dateien des
Cores vom 01.04.14 sind.
Das hieße, dass die PersoApp-Android seitdem kein Updates des Cores erfahren
hat. Jegliche Änderung der persoapp-core-x.x.x.jar im lokalen Maven-Repo
bringen keine Änderung.
Anschließend haben wir versucht die "build_repackaged.jar" händisch zu
ändern. Das einfache Austauschen der Core .class Dateien ist aber nicht
möglich, das die PersoApp-Android teilweise noch auf älteren Core-Methoden
basiert.
Haben wir diesbezüglich etwas falsch gemacht, oder handelt es sich um einen
bisher nicht entdeckten Fehler?
Original issue reported on code.google.com by [email protected]
on 1 Dec 2014 at 10:40
What steps will reproduce the problem?
1. Verbindungsaufbau der mobilen PersoApp zu externen eID Server (nicht
Ageto-eID-Server)
What is the expected output? What do you see instead?
Ausgabe Android Logcat:
1-26 11:40:25.648 32412-32445/de.persoapp.android.debug W/System.err﹕
java.io.IOException: Internal TLS error, this could be an attack
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.org.bouncycastle.crypto.tls.TlsProtocol.failWithError(Unknown
Source)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.org.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(Unknown
Source)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.org.bouncycastle.crypto.tls.TlsProtocol.completeHandshake(Unknown
Source)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.org.bouncycastle.crypto.tls.TlsClientProtocol.connect(Unknown
Source)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.core.tls.BCTlsSocketImpl.<init>(BCTlsSocketImpl.java:90)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.core.tls.BCTlsSocketFactoryImpl.createSocket(BCTlsSocketFactoryImpl.
java:112)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.core.tls.BCTlsSocketFactoryImpl.createSocket(BCTlsSocketFactoryImpl.
java:129)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.core.paos.MiniHttpClient.getSocket(MiniHttpClient.java:142)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.core.paos.MiniHttpClient.getSSLSession(MiniHttpClient.java:119)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.core.paos.PAOSInitiator.<init>(PAOSInitiator.java:167)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.lib.paos.PAOSInitiatorExtension.<init>(PAOSInitiatorExtension.java:6
2)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.lib.paos.PAOSInitiatorExtension$1.createPAOSInitiator(PAOSInitiatorE
xtension.java:27)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.core.paos.PAOSInitiator.getInstance(PAOSInitiator.java:205)
11-26 11:40:25.668 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.core.ECardWorker.<init>(ECardWorker.java:422)
11-26 11:40:25.678 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.core.ECardWorker.<init>(ECardWorker.java:87)
11-26 11:40:25.678 32412-32445/de.persoapp.android.debug W/System.err﹕ at
de.persoapp.core.ECardWorker$1.run(ECardWorker.java:364)
11-26 11:40:25.678 32412-32445/de.persoapp.android.debug W/System.err﹕ at
java.lang.Thread.run(Thread.java:841)i
What version of the product are you using? On what operating system?
A) Mobile PersoApp: Revision 140 des SVN
B) Mobile PersoAPP: fertige APK
http://eid.services.ageto.net/persoapp/PersoApp-Android.apk
Please provide any additional information below.
C) Unser eService + externer eID Server funktionieren mit der aktuellen Version
der offiziellen AusweisAPP unter Windows 8
D) Unser eService + externer eID Server funktionieren mit einer älteren
Version der Desktop-PersoApp unter Windows 8 (2014/09/05 11:16, V0.1b77-0022)
E) Die aktuelle Version des Desktop Pre-Release (2014/09/26 17.53
v1.5b20502-1251 http://eid.services.ageto.net/persoapp/AEC1.0_persoapp.jar )
wirft folgende Fehlermeldung: „Der eID Server versucht ein nicht zulässiges
Protokoll auszuhandeln (TLS1.0 statt TLS1.1+) Wollen Sie fortfahren“
Wenn man dies bestätigt, bricht die Verbindung mit folgender Meldung ab:
"Fehler bei der Verbindung mit dem eID Server".
Der von uns angesprochene eID-Server unterstützt laut Betreiber sowohl TLS1.0
als auch TLS1.1.
In der PersoApp Repository Revision 110 (05.09.14 11:19 Uhr) gab es ein Update
auf BouncyCastle 1.51, wir tippen dass es damit zusammenhängen könnte, da die
ältere Desktop-Variante vom 05.09.14 funktionierte und die neue
Mobil-/Desktopversion nicht.
Gruß Andreas
Original issue reported on code.google.com by [email protected]
on 26 Nov 2014 at 1:44
What steps will reproduce the problem?
1. german perso id not regionised
2.
3.
What is the expected output? What do you see instead?
it shoudt work pcsc-scan does identifi the card on reinersct basic
What version of the product are you using? On what operating system?
prerelese
Please provide any additional information below.
im on ubuntu 10.04(needed for work 16Pc on that system here)
running java8
Original issue reported on code.google.com by [email protected]
on 26 Nov 2014 at 12:04
Attachments:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.