CS Student Capstone (Bachelor's Senior project) for Whonix

Organization
13

Alright, it’s official. We’re clear to start working on the project. I’m not sure if you want to list our team (3 of us) as maintainers, but the odds of us not pushing this project to completion is quite slim. At this point we’d have to redo quite a bit of work if we wanted to do something else. So yeah, we’re moving.

Our current timeline is to push out a hello world super soon, which is where we will need to make sure that we have a way of storing our code that can eventually be merged in when completed. I’m assuming a github repo, correct? That seems to be what our professor desires. This is also our software setup as far as the different working pieces. We could touch base to just make sure it’s all packaged properly, and save us time later.

Then we’ll build a prototype, that contains basic functionality. That should be done by the end of the month, with time to spare for us to get back to you and ensure it’s what you’re looking for.

From there, our plan is to expand outwards, installing additional features (as far as command-line options, quality of life improvements, better support, etc), and eventually, hopefully, moving on to create the outside-vm module afterwards. It’d be nice to have the inside-vm component done by the end of the month in it’s entirety, and after that moving onwards to bigger and better features. One executable that allows the creation of multiple VM’s, and tests that run on those VM’s, would be wonderful. This would involve the outside-inside VM communication as previously discussed, probably over the virtual network using TCP/IP. This would come after the completion of the inside-vm component as a standalone.

From our design meeting: libvirt, and other features that start and stop VM’s would need to run on the host, so those features would actually be part of the outside-vm component, to be built later.

As for the inside-vm component, which is our first priority, software decisions currently are:

behave will be our cucumber-like component. It is python-based and semi-official. It will allow us to keep things in python, with a bash script to get it all going. We’ll eventually create some of your previously suggested test-cases when it comes time to create the prototype.

Dogtail is a possibility for our GUI tool, we’re unsure as to whether or not it’s sufficient, but it has python 3 support so. We’re looking into running that as our working GUI automation tool. Realistically, Dogtail seems to have slow development but it looks mature.

As for any legal stuff, just credit for our work is sufficient. We’ll probably link to the code repo from our github accounts. A resume addition, essentially. Do what you will with it, sell it, whatever.

We’ve also recognized that part of this project involves creating effective documentation as to how to create test-cases and make use of the tool. This should be something that anyone could read, and make sense of. This work is factored in to our plans. It should be easy for other contributors to add test-cases, and we see creating a proper set of test-cases as somewhat outside the scope of our project. We’re just looking to create the test-cases set you suggested, and generally ensure the software is working properly and has all required features. The suite of test cases, and the possible features for the test-case definitions will need to be expanded over time.

As long as it’s sufficient for us to use our own repo, to hopefully be merged when the work is completed, we’ll use the repo previously linked on this post - the one for the project proposal. Our documentation to accompany the software can go on the wiki for that repo.

Thanks for the help, contributions incoming.

2 Likes
14

Sounds great!

Awesome!

Yes. No worries. Feel free to create Whonix wiki accounts (non-mandatory but better for authorship attribution) and add here:

That’s rather informal.

As soon as there’s a hello world, any test of any slight usefulness, this can be merged.

(There are currently other components which aren’t ready for prime time due to missing integration, documentation, testing but already merged because that makes future work easier such as https://github.com/Whonix/hardened-kernel.)

Github is perfect.
(Other stuff could be considered if you see need.)

Yes. Sounds good.
(I wouldn’t even know any other place than the host to run the outside-vm component.)

Yes, sure. Whonix is an Open Source project with the goal of being an exemplary one and attribution is important. I certainly don’t want to be ever criticized for violating any customary attribution guidelines.

  • readme / wiki / etc. can list credits / authors
  • there can be be a credits / authors (or similar file name)
  • git history will include the name and e-mail address of the committer
  • on command line invocation the first (few) lines can show authors, year, copyright information (either following customary formats or own formats)
  • source files top comments design is up to you
  • anything else

Awesome!

(Btw as for selling, as far as I know, this is permitted by all FSF / OSI approved Free Software / Open Source licenses anyhow for anyone who received a copy as per https://www.gnu.org/philosophy/selling.en.html.)

Yes. For sure. That’s the usual git(hub) workflow anyhow.

(For example one original as created GitHub - vmonaco/kloak: Keystroke-level online anonymization kernel: obfuscates typing behavior at the device level. which was then forked using the usual github fork button to GitHub - Whonix/kloak. All git history / previous attribution by the author was kept as is.)

15

Using Dev/Automated Tests - Whonix as a scratchpad for test ideas.

16

Hi @fahr3n,

After discussing with @Patrick, I would love to help you out with the project. I am a software engineer who works mainly with Rails during the day. I have extensive history in automated test suites, SDLC, agile workflows, CI/CD, etc.

I am happy to build a project board, PR templates, code reviews, etc. I think this would be a good thing for your learning as well, as it is very useful for working on professional teams.

You can find me on github @mycobee.

2 Likes
17

This documentation block:

set up your git repository
git init

git remote add origin 'https://github.com/johncameronquinn/wats-senior-capstone.git'

git checkout master

git pull
Can be replaced with one command:
git clone https://github.com/johncameronquinn/wats-senior-capstone.git

But if you want to allow others to contribute you should probably include instructions for forking.

I’d argue that this information should be in the readme, not the wiki. Most developers (IME) want pretty, decipherable markdown in the app root of their project.

Markdown Cheat Sheet

Readme Template:

1 Like
18

There might be a lot advice on how to do that best.

One of my better readme, standalone, more popular (compared to my stuff) github projects:

19

Hey @Mycobee, apologies for taking so long to get back to you! We’ve had a bit of chaos on our end but things are moving again now. I’ll have to check with my professor on you helping out, the only reason why I could see it being an issue is if he’s worried we would lean on your expertise a bit too much. It could possibly make it difficult for him to grade? I am unsure, but I’ll email him now.

About that documentation on the git repo - it’s just a rough placeholder I threw in. Our documentation guy is supposed to be hitting on that soon. We have a private repo we have to maintain for our college which has a more correct install. Thanks for the infographics though, definitely, I’m going to link them to our documentation guy.

1 Like
20

@Patrick, to update you - we got a rough proof-of-concept going. It’s nothing special but it’s opening us up to the possibilities of what this can be. It seems to be satisfying all the needs you conveyed, and helped us understand the limitations of this software.

Honestly, I’m not sure how much updating you’d like from us, but - basic timeline stuff:

We have to have this done in about a month and a half (Poster of the completed project on April 14th). Also, it’s required for all of us to graduate, so, I think that’s why the professor is really specific about things.

As for the software:

Behave is super cool, fully in python - and so writing new tests will require nothing but some basic python code and the super easy Gherkin.

The vision, I’m seeing, is to make adding on to this as easy as possible. Realistically that means we need a sane architecture that is easy to use and expand upon, and robust documentation.

A good example of what I mean:

For Behave, feature files are the natural-language component, and all have to have their own corresponding step definition file ( in Python ).

However, feature files can use step definitions that were defined in other feature files, and no ambiguity is allowed.

So, I wrote a step that could be reused, and the step before it shows an example of how other developer’s feature files could interact with it.

DEBUG_MODE = True

TEST_TEXT = “Hello world!”

@given(‘we are testing nano and xterm’)
def step_impl(context):
# applications placed here can be increased, just don’t spell it wrong
context.testApplications = [“nano”,“xterm”]

@given(‘the application(s) to be tested are installed’)
def step_impl(context):
# execute dpkg on each application to check if it’s installed

for application in context.testApplications :
    # execute, capture output and error
    output = subprocess.check_output(["dpkg", "--status", application], encoding='ascii')
    match=re.search(r'Status: install ok installed', output)

    #no output found, throw an error
    if match is None:
        print(output)
        raise RuntimeError('Success message not found in dpkg status output!')
    else:
        print("for program: %s dpkg found status %s" % (application, match.string)) if (DEBUG_MODE) else print("")            
pass

So the idea is, as long as someone specifies which applications they are testing in their own feature file, ex:

@given('we are testing ‘an_application’)
def step_impl(context):
context.testApplications = [“an_application”]

They could write a Gherkin script with the lines

Given we are testing ‘an_application’
And the application(s) to be tested are installed

And they could reuse the step defined in a separate feature file, which does that testing.

So that’s opening up a larger discussion for us, and we’re studying other implementations. If you or @Mycobee (or whoever else) wants to weigh in on how this should be done, I’m sure it would be very helpful. But, we’re just a bunch of students so I don’t want to waste ya’lls time. Thanks for the help and sorry again for taking so long to get back. Apparently spam filters will eventually target Whonix.

1 Like
21

Well FWIW the task is pretty large, and I don’t think my “expertise” would hinder your learning. I am a backend dev really dabbling on the systems side of things learning also.

I spun up a cucumber repo and have CI working, but now I am trying to use vagrant && libvirt to build the whonix VM for testing. It is a bit challenging. I plan to take another stab tonight.

Once I get a working, testable whonix environment, I am going to focus on kernel testing. Point being, I think it’s pretty easy to work together without stepping on toes. But you are welcome to keep the repo seperate and work on your end. I simply wanted to offer the collaboration aspect since I am already working on it.

IDK how much looking you all have done on the tails source code, but between vagrant, sikuli, libvirt, CI/CD, cucumber, test cases, dogtail, etc…there is no shortage of things to be learned or work to be done. Collaboration and empathy are going to be more important in your tech career than a few python specs IMO. I am happy for as much or as little pleases your professor :slight_smile:

Learning is never time wasted. It is really awesome you are taking this on. For me I think behave seems like it could be a good way to write a suite. I have never used it before.

The feature test BDD layout is great, and IMO the tooling is secondary. I will say that I think it is important to work with the language you are most comfortable in when solving a new problem. I am a big fan of new problem, old technology. Or old problem (like a restful api), new technology. But I am always wary of new problem/new techology.

3 Likes
22

I don’t see any issues. @Mycobee is working has a separate test suite in developing in a dedicated forum thread automated test suite - #7 by Mycobee. The approach is a different one. CI, building Whonix images in CI, then booting these and do kernel testing. While the test suite students are working on is focused on GUI applications. There’s no overlap.

2 Likes
23

Sounds good, my professor also just gave the go ahead for us to work together in general so hey. He just said to document what we do, which should be pretty straightforward, and mostly automatic since we’re doing all our work (including demo wiki pages) on the repo.

Thanks for the good wishes too, I will admit this is a big first for us. I have some project planning experience but this is a particular kind of challenge.

But I am always wary of new problem/new technology.

That’s a good way to look at it, and thanks for the good wishes. I’d love to find a way to integrate both languages.

I heard ya’ll were interested in getting involved with more students too. Most colleges seem to be teaching python as the language they’re most familiar with by graduation. I think it’s the new standard now as the entry-level language that everyone has to get good at (replacing java, seemingly).

It’s something to consider when making and picking projects.

I spun up a cucumber repo and have CI working, but now I am trying to use vagrant && libvirt to build the whonix VM for testing. It is a bit challenging. I plan to take another stab tonight.

So, I have a bit of experience using Libvirt (with QEMU+KVM) on my Arch machine. So if you want any general pointers I might be able to save you a little time. The cool bit I was looking at with Libvirt is how it can simplify making things cross-compatible with different virtualization software . The GUI tool is pretty nice too if you just want something that works, I heard that ya’ll were interested in working with more students, so ease-of-use is always nice.

I will say libvirt broke a lot on my Arch system, but I think that was just an Arch problem.

One bit I just realized: Patrick and I were discussing the inside-vm and outside-vm components, with potential communication between the two. I’m hesitant to expand the scope currently, but it seems like you’re already developing some of what could be an outside-vm component? I suppose that is the start of a larger conversation as to the path forward.

1 Like
24

I wrote the wrong date “completed by 4/29” We’ll actually finish it around 4/14, about a month.

Just clearing up the bad info. I edited the post already.

1 Like
25

I am guessing you mean Ruby and Python? Why? Is there something you can achieve with one that you feel you cant with the other? I’d argue that using a language for the sake of using a language isnt the best use of mental overhead, unless there is a very specific need. Unless I am misinterpreting and you are talking about bringing both our work together in the end, which I dont think will be too difficult with CI.

Concerning my libvirt problems, my challenge was making it play nice with Vagrant. I got unstuck last night after fighting some dependencies and a firmware bug. Currently working on a vagrant file to smooth out the build process.

As for inside/outside, I assume you are talking about nested virtualization (a debian vm running specs against a libvirt whonix vm?), which I plan to do eventually. First goal is get a single VM spun up with CI, then it should be easier to implement whatever nesting is necessary.

No idea yet how that will all look. For me, when it comes to software, it’s easy to get lost in the how and lose sight of the what. Maybe once I have travis, vagrant, and debian vm all working together I will have a better idea of what to do, or maybe not LOL :lab_coat:

1 Like
26

I’d argue that using a language for the sake of using a language isnt the best use of mental overhead, unless there is a very specific need.

I see what you’re saying, I think it’s just we can’t learn a new language and meet our deadlines at this point. Not ideal, but it is the way it is now.

Unless I am misinterpreting and you are talking about bringing both our work together in the end, which I dont think will be too difficult with CI.

I’m definitely interesting in bringing it together in the end. I think we just need to communicate to that regard.

As for inside/outside, I assume you are talking about nested virtualization (a debian vm running specs against a libvirt whonix vm?), which I plan to do eventually. First goal is get a single VM spun up with CI, then it should be easier to implement whatever nesting is necessary.

I’m specifically referring to what Patrick and I were discussing earlier, so not nested in this case. The idea is that some types of tests would have to be run on the host against the guest(s), and other tests would need to be run in the guest on it’s own components. We decided above to develop the “guest testing itself” software, with recognition that there would need to be another piece of software which ran on the host.

Even if our software systems end up having no feature overlap, from a user-standpoint it’d be a little silly if they ended up being totally different in the way one worked with them. As in, we should implement Gherkin in the same manner so that people don’t have to read two different sets of documentation to learn how to write a test case ( and so that we can share documentation rather than writing two completely different sets of wiki pages ).

On a related note, would you like to get in some kind of chat with the group of us? It might be desirable than just communicating it all out here.

1 Like
27

I would love a group chat. For a team I contract with I use slack, so I could do a channel there. It’s proprietary software which I am not the biggest fan of, but on the other hand I am required to use it by both of my employers, so it’s convenient. I also use signal in my personal coms, mostly cell.

I am open to other methods of communication, and working here as well. That is why I initially suggested helping us build an agile project board, bc it could help organize the flow.

1 Like
28

For team chat, Whonix isn’t on slack. The most popular Whonix chat turned out to be telegram. Followed by Matrix.

Link to Whonix telegram also in Whonix wiki footer.

1024px-Telegram 2019 Logo.svg.png Whonix ™ Telegram Chat

If the public chat is too busy, we could create another chat group for automated tests there. (Available mobile and desktop clients).

phabricator any good for that?

https://phabricator.whonix.org/

I wouldn’t worry too much about this. Any coordination might take away time / add complication.
Perhaps writing new tests later on, deciding on which test suite to use, might depend on personal taste and/or goals. Also I wouldn’t want to block the student project due new developments that happen after the initial student project discussion. That’s also because student time schedule of only around 1 month seems rather tight.

Experience has shown that most contributors are interested in shiny new features and before this day nobody ever started actually working on tests. Writing tests / test suites is unfortunately not a very hot topic for contributions. Therefore I am not too worried about too many people having a hard time deciding which test suite to contribute to and really happy to see progress in this important area being made! :slight_smile:

29

I wouldn’t worry too much about this. Any coordination might take away time / add complication.

Therefore I am not too worried about too many people having a hard time deciding which test suite to contribute to and really happy to see progress in this important area being made!

Alright, thanks for the directing. That makes things simpler.

phabricator

Yeah it seems like it has the features: Phabricator/Project management - MediaWiki
I’m personally experienced with Trello, but it’s not that great. It’s simple I guess, does what it needs to.

I am open to other methods of communication, and working here as well. That is why I initially suggested helping us build an agile project board, bc it could help organize the flow.

@Mycobee Right, and since we can freely work together in any capacity, we’re good to go. So, I’m okay with whatever, I’m sure my group members won’t mind too much either. The stuff Patrick suggested works, maybe make our own group on Telegram so we can have a good chat history?

As for the project board, lead the way? Haha.

1 Like
30

Looks like Phabricator can work fine @Patrick , I am just getting that and telegram setup now. I was planning to create issues with Github projects, but I am fine to keep it all centralized on Phabricator.

Would you mind making a project for WATS on Phabricator please? Where I am allowed to create issues? I don’t have permissions at the moment. Name is mycobee on Phabricator

Also @fahr3n, I am on telegram now in the group room, if you want to start a group message for strictly the testing collaboration. Name is bee on there too.

I put updates on my side of things in my thread btw:

1 Like
31

done: WATS

Fixed.

Created a public group (I guess don’t need private group):

Add @Mycobee and @fahr3n already.

32

Any update?