The latest release is old #133
Comments
|
..and upload it to the F-Droid repos? |
|
Apparently it cannot be build on F-Droid, it is stated here: https://f-droid.org/wiki/page/com.nowsecure.android.vts |
|
A new release would be great and the option or a textfile how this can be used individually to root a smartphone when towelroot-bug is fixed and Samsung locked the bootloader. So this would be a chance to succeed in rooting. |
|
would love a new release. |
|
Can someone build the latest relase please ? |
|
Isn't it possible? |
|
When I download the latest app from 2015 does it test for vulnerables from last year (2016)? If not - how can I achieve this? |
|
Download the latest release from the official page. |
This release you a pointing is from Dec 15, 2015 and has logically only CVE's to this date. I wan't to figure out how to test against (new) vulnerables from last year (2016)... |
|
download and build from source is only option I'm guessing, seems no one is release the builds any longer then. |
Too bad that I'm not able (like 99%) to do this... Meanwhile I go with x-ray (https://labs.duo.com/xray). They have quite recent builds. I like Android-VTS much more but as a matter of security... |
|
X-ray is too very old and only checks cves back to 2015. |
Hell... damned! The binary is from jul '16... but as you said.. no active development Anyway... looks like security gone out of fashion. Maybe it's time to de-publish here... |
|
I'll start a fork and doing some initial work. We are facing MIT license so there should be no problem. If any wants to help, drop me a message. |
|
@ManuelGysin Maybe trying to ask write access to the official repository to @dweinstein and @Fuzion24 first would be better. This is what I usually do. Forking a project and drive existing users to it is always hard: users not aware of the fork, lack of advertising, etc. |
|
I would first the establish some progress on the fork before asking for write permissions. If the project finds back to life, maybe the original authors may continue their work. |
|
AFAICT xray's more recent release had just been a white labeling of VTS. We were hoping that they would help by adding support/upstreaming new tests but so far that hasn't really been the case. To be honest, in order to continue directly supporting this project we would need more support/sponsorship from perhaps another vendor that is benefiting from the project. We've heard of a number of bigger companies getting the benefit from this tool. It takes a good amount of time to bring in new CVEs and to maintain releases. |
|
@dweinstein: What about setting an automated tool to compile nightly builds or perhaps weekly? There are some free services for this and after setting it won't require manual intervention. |
|
I think build the release is not the problem. I'm currently creating a list with CVEs we can check and one we can't. For some we can adopt PoC code directly for testing, for others we need to start from scratch. I think we should start we the boring part and create a ToDo list. After that we can start to get help. Maybe we should write to some Linux sites too and make some noise about the current situation. In reality a customer has no idea if the patch level is correct and all needed CVEs are fixed. It's just a string in a property file. So a real test framework is needed to verify ROM builds. This is an important topic and we should communicate this to the community. I don't think the big players will support this project, so we need community work. In fact with a small team this should be possible. I will open an issue later with the lists included. So we can try to organize. |
|
Thanks
…On Thu, Jan 26, 2017, 5:56 PM Manuel Gysin ***@***.***> wrote:
I think build the release is not the problem.
The big work is to add the testing code for every CVE. In fact a lot of
them are not even possible to check, because Mediatek/Nvidia/etc. do not
provide usable information. So we can only add CVEs with proper description
and source access.
I'm currently creating a list with CVEs we can check and one we can't. For
some we can adopt PoC code directly for testing, for others we need to
start from scratch.
I think we should start we the boring part and create a ToDo list. After
that we can start to get help. Maybe we should write to some Linux sites
too and make some noise about the current situation.
In reality a customer has no idea if the patch level is correct and all
needed CVEs are fixed. It's just a string in a property file. So a real
test framework is needed to verify ROM builds. This is an important topic
and we should communicate this to the community.
I don't think the big players will support this project, so we need
community work. In fact with a small team this should be possible.
I will open an issue later with the lists included. So we can try to
organize.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#133 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AXtz3xEXrBrWXC0MZY8hXjBFvXGIYq9eks5rWU7cgaJpZM4JZAsY>
.
|
|
@ManuelGysin: I agree to most of things you said but build release or beta IS a problem because code in git is updated at "9 Aug 2016" while latest release is updated at "15 Dec 2015" so there is unreleased code. The users will likely stop using the project after seeing this. |
|
This seems right. But building it shouldn't be that hard. If wished I can provide a cloud build VM for newer release. (We need to setup Jenkins for an other project anyway for my organization) |
|
@ManuelGysin: I think it would be really great and it could gather interest in the project. |
|
This issue can be resolved by simply bumping the version[Code|Name] to v.14 in build.gradle, then building the latest APK and uploading it to the Releases page here: |
|
ok sorry for this, I totaly forgot you but I made the change: |
|
@nailyk-fr it shouldn't need to depend on AOSP, though |
|
It would be nice if someone change the build script to compile the files in android-vts/app/src/main/assets/ instead of use the prebuilt binaries and submit a pull request. |
|
Temporary fdroid repo #38 (comment) until official f-droid came back. |
The latest release is more than 1 year old, is it possible to do a new release?
The text was updated successfully, but these errors were encountered: