Skip to content

Conversation

Gopinath-Mahendiran
Copy link

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

How did you test this?

  • [ x] Manually - Verified that api_key is encrypted when stored.
  • [ x] Manually - Confirmed api_key decryption works correctly.

###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.

neiljp and others added 30 commits April 12, 2023 14:32
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.
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.
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.
@Gopinath-Mahendiran Gopinath-Mahendiran force-pushed the Gopinath-Mahendiran branch 2 times, most recently from e23df1f to 04fd0ae Compare March 24, 2025 04:58
@Gopinath-Mahendiran Gopinath-Mahendiran force-pushed the Gopinath-Mahendiran branch 2 times, most recently from 04fd0ae to 23a773c Compare April 1, 2025 18:02
@Gopinath-Mahendiran Gopinath-Mahendiran force-pushed the Gopinath-Mahendiran branch 8 times, most recently from 4ea856e to a1132b8 Compare April 13, 2025 19:10
@Gopinath-Mahendiran Gopinath-Mahendiran force-pushed the Gopinath-Mahendiran branch 8 times, most recently from e1e00d8 to 1137f07 Compare April 26, 2025 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.