Closed iceman1001 closed 5 years ago
As for EMV:
14a sim
command with next behavior:
commands from client go to arm side and returns (like android host emulator)
so it will be online emulator, because there will be many data structures. it will be easier to make it on client side
What do you think? We are not going to change argument parsing in this release. That is a later and huge change. We just need need to have your EMV to a certain point. Like your next PR. And that will fine for this release. I'm most concerned about PM3 being slow from the thread changes... That is a show-stopper.
All the rest of your ideas for emulator, json, scanner, is not to be discussed in this issue. It should have a thread on the forum instead.
Agree with @iceman1001. It is again time to stabilize after approx. 200 commits since 3.0.1.
What do you think about separate branches for the releases? E.g. we would now create a stable_3_1_0 branch and let homebrew point to this branch. This would allow us to backport bug fixes which may occur on master branch later.
That is great idea, @pwpiwi Now why haven't we done this before?
I'd like to get #463 and #506 landed in this release so I can target a stable release for Android porting work. I've ended up writing a hack to blow away most of the context.
3) pm3 slowness, related to #463. Looks like @pwpiwi has not gotten the answers he needs in order to accept it. Needs to be resolved.
Sidenote, not to be discussed in this issue but in its relevant issues. Problem is @micolous PRs is that the pm3-as-a-lib is not going into PM3 Master. Once we can stop spending time looking at code that could already been in a branch, by-it-self, and focused on fixing non-working items in the source, this process could have been so much faster.
With EMV part4 merged, it will do fine for a release with 'hf emv'
hf 14a apdu
works. I have not seen any improvements.
@iceman1001 To be clear, I'm not trying to shove the whole "pm3-as-a-lib" into next release, I'm trying to get the comms refactor stuff in there. That does mean I've done some really ugly hacks inside my (Android) code to reinitialise PM3 client global state. Long term I want to get rid of it.
My goal is to put enough of the code changes into PM3 upstream that I need for Android -- most of the stuff I've done is written on the side with custom build scripts: https://github.com/AndProx/AndProx/tree/master/natives/src/main/cpp
Idea being that whatever you folks decide to cut as 3.2.0, I can point AndProx at and it would "just work" without major source modifications, and Android becomes a platform like every other.
I'm only after getting #463 (which was approved a month ago) and #506.
@micolous I love the effort you put into your project and wish you good luck with your android app. To be clear, "pm3-as-a-lib" will not make into PM3 Master. The repo-owner has said so. He shares the idea that you can put it all in a branch, or make a new repo for your pm3 version.
Regarding this release issue: The #506 still suffers from not unifying the different methods to abstract the printandlog function, as I commented there awhile ago. Once you unify that, I see no problem with getting #506 merged.
recap,
Number 3, is the current showstopper for a new release. @pwpiwi ?
The re-connect client functionality would be nice, ( #516 ) but I'm not sure it fiddles with ( #463 )
Number 3, is the current showstopper for a new release. @pwpiwi ?
I am testing something. There is a small chance...
BTW: why would we skip 3.1.0 ?
So you noticed the skip in version numbering... Funny thing version tags on GitHub and forks. If someone add a version tag in his fork, once you merged with the original repo, it all mixes.. making tags have the same version numbering. This is my own mistake, so in order not mess up confusing for ppl with v3.1.0 which did exist in iceman fork, I change my own version tags name to clearly be seperate from PM3 Offical ones. However the v3.1.0 problem exits still, so solution is to skip all of that, with a v3.2.0 here, and my own names in iceman fork which should indicate about which pm3 offical it is on pair with. I don't want to introduce confusion for users. lesson learnt from that.
Well, if someone else verifies thehf mf sniff bug, then it would be a showstopper aswell.
it looks that release is ready
No, not yet but close to it.
The following would be needed: https://github.com/Proxmark/proxmark3/pull/566 https://github.com/Proxmark/proxmark3/pull/516
and we still have the slowness from 6sec to 12.5 sec, the pm3 almost feels like its broken when it comes to the enumeration of OS-host.
But after that, it is ready for release.
Current status:
Since the slowness is not addressed in #463 that PR is not required.
The only thing left is the reconnect functionality PR #516.
Does someone have any opinions?
hi)
any news on release?
Still unstable for OSX users (Issues #283, #497 and #627).
Released v3.1.0. Thanks to @drandreas and his OSX fix.
The release seams to be gone. Was there an unexpected issue?
Thanks for noticing. It had been reverted to draft (probably because I had tried to replace the lightweight tag with an annotaded tag). Should be back now.
I'm opening up for discussions on when the next offical pm3 release should be published.
I suggest that after the following items it would be fitting.
I also suggest new version to be v.3.2.0 since we have the new commands.