Differences
This shows you the differences between two versions of the page.
|
ii:labs:04:tasks:01 [2021/12/05 20:44] radu.mantu |
ii:labs:04:tasks:01 [2024/11/20 16:02] (current) florin.stancu created |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== 01. [??p] Commit signing ==== | + | ==== 01. [20p] Enhancing your environment ==== |
| - | When looking at the ''git log'' of a repository, you would normally see a sequence of entries such as this: | + | Just like last time, you'll need to create a virtualenv in order to install specific libraries. |
| - | [[https://ocw.cs.pub.ro/courses/_media/ii/labs/04/tasks/git_log.png|{{ :ii:labs:04:tasks:git_log.png?700 |}}]] | + | [[https://ocw.cs.pub.ro/courses/_media/ii/labs/03/tasks/venv-demo.gif|{{ :ii:labs:03:tasks:venv-demo.gif?700 |}}]] |
| + | <html><center><i> Click GIF to maximize. </i></center></html> | ||
| - | Each commit is identified via a 40-character long **hexstring**. A hexstring is the hexadecimal representation of a sequence of bytes, where every nibble (i.e.: 4 bits) is represented by a character ranging from //'0'// (= 0b0000) to //'F'// (= 0b1111). But how is this identifier calculated? | + | === [10p] Task A - Dependencies === |
| - | Well... this commit identifier is called a **hash value** or a **digest**, and is the output of a [[https://en.wikipedia.org/wiki/Hash_function|hash function]]. A hash function takes an arbitrary amount of data and outputs a fixed-size bit array that is representative of the input. Normally, one would be weary of collisions: if the function's domain is virtually infinite and the co-domain is not only finite but rather small in comparison, wouldn't it be possible to create two commits with the same digest? Possible -- yes, likely -- no. Git uses **SHA1**, a [[https://en.wikipedia.org/wiki/Cryptographic_hash_function|cryptographic hash function]]. What makes a __cryptographic__ hash function so special is that it provides certain guarantees. For example, it should be impossible to calculate potential messages from a digest (meaning that the function is non-invertible). Moreover, any change in the input -- no matter how small, should change the hash value so extensively that the new value and the old should appear uncorrelated. As such, being able to //craft// a commit such that it's not only comprehensible, but also creates a certain desired digest is so unlikely that it occurring naturally should not pose any risk. | + | First, if you reinstalled your Linux/WSL/VM from last time, ensure that you have the prerequisites installed (it never hurts!): |
| - | There is, however, a more significant risk here. What guarantee do you have that the author of the commit above is actually Linus himself? Using something like [[https://github.com/jayphelps/git-blame-someone-else|git-blame-someone-else]], you could overwrite commits and change their author only to then ''%%git push --force%%'' and replace the remote history. The answer to this problem is **commit signing**. Cryptographic algorithms can be loosely categorized an **symmetric** and **asymmetric**. Symmetric algorithms like [[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard|AES]] use the same key for both encryption //and// decryption. Asymmetric algorithms like [[https://en.wikipedia.org/wiki/RSA_(cryptosystem)|RSA]], on the other hand, utilize two keys. One for encryption and one for decryption. Usually, the one used for encryption is called the private key and the one used for decryption, the public key. The private key is your identity, so you don't share it with anyone. The public key you configure on remote servers to give them the ability to verify your identity (e.g.: configuring SSH keys on fep.grid.pub.ro). As a rule, you use asymmetric cryptography in cases where you need to prove your identity to a remote host, establish secure communication channels, negotiate session parameters, etc. The reason for this is that asymmetric algorithms are __orders of magnitude slower__ than their symmetric counterparts. While encrypting the output of a **SHA256** function (32 bytes) with a 4096-bit RSA key takes about 5ms on regular CPUs, it takes almost a __full minute__ on an Arduino Mega (with a MCU running at 16MHz). AES-256 on the other hand, encrypts the same amount of data in less than 5 __microseconds__. The downside is that you need to share your key with other systems for them to extract the plaintext message. | + | <code bash> |
| + | sudo apt install python3 python3-venv python3-pip | ||
| + | </code> | ||
| - | In the following tasks we will introduce **GNU Privacy Guard (gpg)** an open source encryption and signing tool. **git** can use **gpg** to sign your commits as you create them. For it to work, you will also have to upload your public key to [[https://github.com/settings/keys]]. | + | Navigate to your work directory, e.g., ''lab04'' and build your virtual environment: |
| - | === [??p] Task A - GNU Privacy Guard === | + | <code bash> |
| + | mkdir -p lab04 && cd lab04 | ||
| + | python3 -m venv .venv | ||
| + | # don't forget to activate your environment each time you start a new shell: | ||
| + | source .venv/bin/activate | ||
| + | </code> | ||
| + | |||
| + | Now, to get to the specifics of today's lab, we need some extra dependencies: | ||
| + | |||
| + | <code bash> | ||
| + | # you need extra system libraries installed with your distro's package manager | ||
| + | sudo apt install libffi-dev libnacl-dev python3-dev | ||
| + | # and our target Python libraries: | ||
| + | pip3 install 'py-cord[voice]' PyNaCl ipython | ||
| + | pip3 list | ||
| + | </code> | ||
| + | |||
| + | So, what are these, exactly? | ||
| + | |||
| + | * **PyNaCl**: wrapper of the [[https://nacl.cr.yp.to/|NaCl]] library. This library offers a high-level interface for networking and cryptographic operations. Note that the library must be installed using **apt** and that which we install with **pip** is only a wrapper. | ||
| + | * **py-cord[voice]**: a //Python// module that interacts with [[https://discord.com/|discord]]. The previous [[https://discordpy.readthedocs.io/en/stable/|discord.py]] project has been discontinued and [[https://docs.pycord.dev/en/master/index.html|pycord]] remains the best alternative. We'll be using this in the following exercise to write a discord bot. | ||
| + | * **ipython**: a more interactive //Python//. See the next task for some details, but there's really not much to it. | ||
| + | |||
| + | === [10p] Task B - Testing that it works, with ipython === | ||
| + | |||
| + | In the previous labs, you used the **python3** interpreter in interactive mode. Now, we upgrade to **ipython**. This new interpreter offers an enhanced user experience by means of color coding, tab completion, multi-line editing, etc. For scripting purposes, **python3** should remain your interpreter of choice. But for prototyping, we suggest using this. For now, let's see if the **discord** module in the **py-cord[voice]** package is available to import. | ||
| + | |||
| + | <code python> | ||
| + | $ ipython | ||
| + | Python 3.9.7 (default, Oct 10 2021, 15:13:22) | ||
| + | Type 'copyright', 'credits' or 'license' for more information | ||
| + | IPython 7.29.0 -- An enhanced Interactive Python. Type '?' for help. | ||
| + | |||
| + | In [1]: import discord | ||
| + | |||
| + | In [2]: discord? | ||
| + | |||
| + | In [3]: discord?? | ||
| + | |||
| + | In [4]: help(discord) | ||
| + | </code> | ||
| + | |||
| + | Note how in stead of **help**, in **ipython** we can ''?'' or ''??'' to something to access a brief / more complete documentation. | ||
| + | |||
| + | <note important> | ||
| + | If you can't import the **discord** module, try to source the activation script again after installing the packages with **pip**. Some versions of **venv** / **pip** might act up. | ||
| + | </note> | ||
