duzzuti / passwd-manager Goto Github PK

• Location/Files:
  api, api.cpp
• Current behaviour:
  it is not compiling because of this error:
  error occures in/since this commit

error: expected primary-expression before '.' token, line 104
 if (FModes(file_mode.getBytes()[0]) == FData.getFileMode()) {

You cannot call FData methods, because its a template parameter.

• Reproducing steps:
  see above
• Wished behaviour:
  FData should only be a generic for a few classes that deriving from FileData (which has this method implemented)
  How do we make FData a template of only a few classes and call these methods generic?

• Difficulty (1-10):
  it will take some time
• TestFiles:
  all
• Which code gets tested:
  a few parts
• What should be done:
  we have to add all way more unittests.
  To do that we have to ensure that every function has one task #18
• each function does only do one task

Testing:

1. add am unittest for each function to test:

• its input and output types (signature)
• its behaviour

2. add an unittest for each class, to test out the API of the class over the lifetime of the object

• Difficulty (1-10):
  2
• Location/Files:
  src/password_data.cpp
• Current behaviour:
  PasswordData.showSets() is not implemented yet
• Wished behaviour:
  Implement this functionality.
  It takes a substring as an argument. You should output all sets which's site name contains this substring
  One set should be displayed per line (use std::cout for output)
  A set contains site name, user name, email, password. User and email are optional (empty string means not set)
  You can find this data in an unordered map this->siteMap. The key of the map is the site name string.
  The value is a vector with 3 entries (user, email, password)

Summary:

• output one set per line.
• the site name contains the given substring (note that a substring "" should display all sites)
• IGNORE the substring's case
• format the output (tablelike with site name username , email, password as columns)
• Bonus: sort the output alphabetically
• you can delete the const from the argument if you need to edit it (delete it from include/password_data.h too)

Good luck

Instead of interacting with the app with the current conversational menu style it would be more efficient to use a CLI style.

• Difficulty (1-10):
  6

• Current behaviour:

./pman

• Wished behaviour:
  For example

pman --help
pman --encryptfile [ ] --iterations [ ] --encrypmethod [ ]

• Difficulty (1-10):
  2

Use a github workflow to automatically format all the code in a PR to the given style.

Reference: https://github.com/jidicula/clang-format-action

• Difficulty (1-10):
  its not easy to test a whole api

• TestFiles:
  src/api

• Which code gets tested:
  the whole API

• What should be done:
  Due to #30, this is the current state

  • deleted templates
  • create new documentation
  • finishing implementing the API class
  • testing the API class

  This issue handles the testing of the api class which should be added

• Difficulty (1-10):
  1
• Location/Files:
  look in pwfunc/isPasswordValid() and app/askForPasswd()
• Current behaviour:
  If the user inputs an invalid password, the current response is just a message that the password was illegal.
• Wished behaviour:
  You have to implement a function that returns why the password was not valid.

• Difficulty (1-10):
  4 (not hard, but lots of work)
• Location/Files:
  all
• Current behaviour:
  no logging is done in the currently app
• Wished behaviour:
  use PLOG (which is already working) to log activity while the app runs.
  It has not be done all at once.

Many IO components have a very bad structure and are not working
They have to be refactored. The application has to be done in layers, the main priority is the architecture.
There will be more focus on UI later (after the TLA is working)
Following components are meant:

• filehandler
• app
• chainhash ask methods

Due to #30, this is the current state

• deleted templates
• create new documentation
• implement the API class
• testing the API class

The next step is to adapt the documentation to the new state.
The current documentation "api.md" is out of date.

We should ensure that functions should have two properties:

1. The name is relevant for what they do
2. The function does one single thing.

Specially if we notice that property number 2 isn't fulfilled we should split the function into as many different things is doing. Following this idea makes the code much easier to read and debug.

• Difficulty (1-10):
  2

Due to #30, this is the current state

• deleted templates
• create new documentation
• finishing implementing the API class
• testing the API class

This issue handles the actual implementation which should be added

• Difficulty (1-10):
  3
• Location/Files:
  pwfunc.h/pwfunc.cpp
• Current behaviour:
  A chainhash is an hash which is applied on its previous result (for a given number of iterations).
  You can copy some code from the implemented chainhashes.
  use this->hash->hash() as the hash function.
  there are already 4 types of chainhashes imnplemented.:
  1. A chainhash which hashes the last hash again
  2. A chainhash which hashes the last hash + a constant salt
  3. A chainhash which hashes the last hash + an incrementing number
  4. A chainhash which hashes the last hash + a constant salt + an incrementing number
  5. A chainhash which hashes the last hash + a quadratic salt #4
• Wished behaviour:
  New chainhashes wished
  Define you own chainhash function in the pwfunc files.
  Constraints:
  1. it has to take at least a std::string password and an iteration number
  2. it can take more arguments if needed, but all added arguments have to be under 256 Bytes memory (because we have to save them in a buffer, this constraint is more theoretically but you should not expect long strings or other big data to get passed)
  3. the result has to be the same with the same arguments (obviously)

if you need help or have a hard time understanding certain things, you are welcome to comment on this issue

Good luck

This is a nice logger library for C++: https://github.com/SergiusTheBest/plog

• Difficulty (1-10):
  2

In this issue, i am gonna handle the software modeling.
I will use UML to abstractly show the software.

That will help in various ways:

1. It will help to detect refactoring potential
2. It helps detecting bugs
3. It helps to detect issues in the relationships of objects
4. It helps to get a better understanding about the software
5. It helps to get an overview over all components
6. It helps to extend the software by showing the available interfaces
7. It helps to adapt the software to other interfaces more efficient
8. It helps to implement design patterns
9. ...and many more

add optionals to structs and access functions to avoid pre-defining objects with no default constructor

• Difficulty (1-10):
  3
• TestFiles:
  pwfunc_unittest.cpp
• Which code gets tested:
  pwfunc.cpp/.h methods getting tested
• What should be done:
  you need to add unittests for the overloaded chainhashes which are taking Bytes instead of std::string as the first argument.
  You can copy code from the other functions but you have to generate Bytes (RNG::gen_rand_bytes() should be helpful)

Good luck

• Difficulty (1-10):
  3
• Location/Files:
  pwfunc.h/pwfunc.cpp
• Current behaviour:
  A chainhash is an hash which is applied on its previous result (for a given number of iterations).
  You can copy some code from the implemented chainhashes.
  use this->hash->hash() as the hash function.
  there are already 4 types of chainhashes imnplemented.:
  1. A chainhash which hashes the last hash again
  2. A chainhash which hashes the last hash + a constant salt
  3. A chainhash which hashes the last hash + an incrementing number
  4. A chainhash which hashes the last hash + a constant salt + an incrementing number
• Wished behaviour:
  New chainhashes wished
  Define you own chainhash function in the pwfunc files.
  Constraints:
  1. it has to take at least a std::string password and an iteration number
  2. it can take more arguments if needed, but all added arguments have to be under 256 Bytes memory (because we have to save them in a buffer, this constraint is more theoretically but you should not expect long strings or other big data to get passed)
  3. the result has to be the same with the same arguments (obviously)

if you need help or have a hard time understanding certain things, you are welcome to comment on this issue

Good luck

Since this project is partially aimed at developers improving their C++ and CMake skills I create this issue. The issue should be constantly ongoing and if we realize that some of our practices in CMakeLists.txt are not ideal we should make a PR referencing it.

This is a nice source to learn about the modern best practices for CMake: https://cliutils.gitlab.io/modern-cmake/

• Difficulty (1-10):
  2

• Location/Files:
  CMakeLists.txt

• Difficulty (1-10):
  1

• Location/Files:
  Any *.h file

• Current behaviour:

#pragma once
#ifndef APP_H
#define APP_H

• Wished behaviour:

#pragma once

• Extra info
  https://www.learncpp.com/cpp-tutorial/header-guards/

• Difficulty (1-10):
  4
• Location/Files:
  new file include/timer.h and src/timer.cpp required
• Current behaviour:
  there is no timer implemented yet
• Wished behaviour:
  You need to create these two files named above and create a timer class.
  This timer class should match following specifications:

1. a start() method to start the timer
2. a stop() method to stop the timer and saving the time needed since the last start() or recordTime() call
3. a recordTime() method to save the time needed since the last start() or recordTime() call
4. a peekTime() method which returns the time passed since the last record or start call
5. a getAverageTime() method which returns the average time per record and stop (getTime() / getLaps())
6. a getTime() method which returns the timedelta between the start and stop call
7. a getLaps() method which returns the number of recordTime() and stop() calls (the total number of measurements you made)
8. you can be creative and think up your own useful methods

Each timer can be started only once and stopped (aftera start()) only once.
If the user starts the timer a second time (after the first stop() obv), the measurements of the previous start() -> stop() cycle should be deleted.
Note that only the methods 1-4 can be called before a stop(). The user has to call stop() first to use the other methods. (Otherwise the timer can throw and execption)
All time measurements should be im miliseconds (unsigned long).
You can use an std::vector to track the recordTime() lap times.

Good luck