forked from zulip/zulip-terminal
-
Notifications
You must be signed in to change notification settings - Fork 0
Secure api_key storage in zuliprc with automatic & manual encryption #4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
Gopinath-Mahendiran
wants to merge
276
commits into
neiljp:main
Choose a base branch
from
Gopinath-Mahendiran:Gopinath-Mahendiran
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Secure api_key storage in zuliprc with automatic & manual encryption #4
Gopinath-Mahendiran
wants to merge
276
commits into
neiljp:main
from
Gopinath-Mahendiran:Gopinath-Mahendiran
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This enables the STATE_ICON lookup to be typed more cleanly.
This significantly reduces code duplication. Note added in ui_mappings that the order is relevant in the UI.
Bots do not have a dynamic status, so give them a static one.
These are constructed dynamically based on the user status, so if a user may have a "bot" status, a "user_bot" style is now necessary.
This will be picked up using earlier commits, to show it differently in the UI. With a different status, bots are now explicitly placed at the end of the user list. Tests updated. Original logic by Progyan, simplified using logic suggested in review by neiljp in zulip#1187. Co-authored-by: neiljp (Neil Pilgrim) <[email protected]>
This does not modify content, only shortens lines to make diffs easier to read. Visually compared to previous version as rendered on GitHub to ensure no changes.
Thanks to Vishwesh Pillai <[email protected]> for discovering this.
The note relating to zulip#1145 is retained, but testing in CI indicates a more specific error is given if there is no matching python for a user's environment - now that versions 0.2.0 and 0.2.1 have been yanked from PyPI. Instead of a broken install of a very old version, a recent pip should error with a message along the lines of `ERROR: Package 'zulip-term' requires a different Python: 3.11.3 not in <3.11,>=3.7'`
The latter form has officially been the narrow format, but the server was previously looser in also accepting the underscore version - though that was subsequently reverted. For details see (on chat.zulip.org): - #zulip-terminal > Cannot narrow to `pm_with` (#T1352) - #api design > direct message search operators Tests adapted. Commit text updated and commits squashed together by neiljp (all changes are necessary together to keep ZT functioning)
This extends the existing behavior which only matched against the start of the topic, and applies in entering the topic in the compose box as well as linking to streams and topics in message content. A similar approach is taken as with streams, splitting on spaces as well as a set of additional delimiters (-_/). The topics fixture is extended to include text split by delimiters. Test cases updated and extended. Fixes zulip#1358.
This field could previously be an arbitrary `str`, though in practice `Message`s come from the server and `Composition`s are sent from ZT, so only the latter directly benefits from matching strings to these limited values. DirectMessageString is used here, though other naming has yet to migrate towards "direct" rather than "private". Fixture updated to use MessageType instead of str.
Comment adjusted; Final applied to new constants.
With the addition of stream typing notifications, and soon the migration to "direct" in place of "private", message type can now be useful to include. However, note that we don't yet explicitly specify the type for the direct/private message form, since this was added only in ZFL 58, Zulip 4.0.
Add small section in README to document the benefits.
Prior to this commit, while the tool is installed in every development environment, installing the hook was simply 'highly suggested'. This rephrases the text to improve the motivation for using gitlint, including running it manually, and then showing how automating it is therefore useful. This section still follows the general commit message style section; it may be necessary to refer one to another, or otherwise combine them to improve motivation towards using this tool. Alternatively, gitlint could be added to CI.
Various notes were previously added to this documentation. This commit reorganizes text in these sections to improve readability, including raising the section level of the Editing, Linting/testing, and Commit sections. In particular, this should more clearly explain, in order: - when checks are run on GitHub - that they can be run locally and why that's useful - the expectation of passing all linting and tests for a PR to be merged - ideas of what to do if linting/tests don't pass
This parameter was previously simply passed the value of the object, so just use self instead. It was also erroneously named message_view, whereas the relevant object was a message_box. Tests updated, including one test case previously not being run correctly.
This improves the naming at call sites, as well as enabling clear additional usage and reduction of duplicated code in main_view(). Tests updated.
Fixture updated.
This avoids explicitly setting it from the caller after initialization, and the need for hasattr checks where it is used. Tests updated.
While this is currently only used in this project, there is no need to make it so specific. Tests updated.
None is much simpler to check, compared to Set[None]. Tests and fixtures updated.
…#1393. Test updated and slightly reworded.
This makes it easier to look up symbols elsewhere, though it is also useful to continue having the symbols directly in the strings, to allow them to be viewed easily in the source.
Previously all symbols were assumed to be simple variables only. This change enables expanding entries stored in a dict. For example: NAME = dict(A=x, B=y) results in entries in the UI listed as: NAME__A=x NAME__B=y.
When multiple users shared an emoji reaction, the prior implementation did not account for individual user IDs, leading to buggy handling of 'remove reaction' events.
In preparation for deprecation of `user` field from reactions. Tests added.
- reaction_event_factory - reaction_event_index_factory To test the handling of reaction events conforming to the reactions schema post ZFL 2.
The "user" field is to be deprecated from messages' reactions and reaction events in the API. Add support for `user_id` in MsgInfoView, by using the recently introduced `get_user_id_from_reaction()`. Remove dependence on reaction["user"]["full_name"] by instead using `_all_users_by_id` with the "user_id". Tests updated.
e23df1f
to
04fd0ae
Compare
04fd0ae
to
23a773c
Compare
4ea856e
to
a1132b8
Compare
e1e00d8
to
1137f07
Compare
1137f07
to
71a3384
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR enhances security by encrypting the api_key stored in the zuliprc file. It ensures that sensitive credentials are not stored in plaintext, reducing the risk of exposure. A decryption mechanism is also included to seamlessly retrieve the api_key when needed.
Outstanding aspect(s)
External discussion & connections
topic
How did you test this?
###How this behaves
When a user logs in directly from the terminal without downloading the zuliprc file from the web application, the encryption process will be handled internally, ensuring a seamless and secure experience.
However, if the zuliprc file is downloaded from the web application, encryption must be performed manually using the following command:
zulip-term --encrypt <file_name>
This command encrypts the api_key stored in the file, enhancing security before use.
Regardless of whether the user logs in with the default zuliprc file or a custom configuration file, decryption will be handled automatically within the application. This ensures a smooth authentication process without requiring any manual intervention.