[GH-ISSUE #336] Is history encrypted? #186

Open
opened 2026-03-03 01:10:45 +03:00 by kerem · 21 comments
Owner

Originally created by @xdxdy on GitHub (Jan 20, 2019).
Original GitHub issue: https://github.com/Clipy/Clipy/issues/336

I'm just worried about that some other apps may just copy the history files and then can know many things, even username, and password.

Originally created by @xdxdy on GitHub (Jan 20, 2019). Original GitHub issue: https://github.com/Clipy/Clipy/issues/336 I'm just worried about that some other apps may just copy the history files and then can know many things, even username, and password.
Author
Owner

@justintaylor-dev commented on GitHub (Jan 24, 2019):

@xdxdy doesn't look encrypted, just slightly obfuscated in the prefs file:
/Users/[username]/Library/Application Support/com.clipy-app.Clipy/default.realm

<!-- gh-comment-id:457385603 --> @justintaylor-dev commented on GitHub (Jan 24, 2019): @xdxdy doesn't look encrypted, just slightly obfuscated in the prefs file: `/Users/[username]/Library/Application Support/com.clipy-app.Clipy/default.realm`
Author
Owner

@xdxdy commented on GitHub (Jan 25, 2019):

Would it be encrypted in the future?
For everyone using pass manager, plain text history record would be a disaster.

<!-- gh-comment-id:457524186 --> @xdxdy commented on GitHub (Jan 25, 2019): Would it be encrypted in the future? For everyone using pass manager, plain text history record would be a disaster.
Author
Owner

@justintaylor-dev commented on GitHub (Jan 28, 2019):

@xdxdy I agree, I'm gonna start looking for an alternative which is a shame cause I really love using Clipy.

@Econa77 any plans on upping security?

<!-- gh-comment-id:458258569 --> @justintaylor-dev commented on GitHub (Jan 28, 2019): @xdxdy I agree, I'm gonna start looking for an alternative which is a shame cause I really love using Clipy. @Econa77 any plans on upping security?
Author
Owner

@justintaylor-dev commented on GitHub (Jan 28, 2019):

@xdxdy I also noticed that clearing your history, doesn't remove any previous clipboards from this file.

<!-- gh-comment-id:458260971 --> @justintaylor-dev commented on GitHub (Jan 28, 2019): @xdxdy I also noticed that clearing your history, doesn't remove any previous clipboards from this file.
Author
Owner

@xdxdy commented on GitHub (Jan 30, 2019):

@xdxdy I also noticed that clearing your history, doesn't remove any previous clipboards from this file.

Yes, I really think that it needs a reliable encrypt.

<!-- gh-comment-id:458807846 --> @xdxdy commented on GitHub (Jan 30, 2019): > @xdxdy I also noticed that clearing your history, doesn't remove any previous clipboards from this file. Yes, I really think that it needs a reliable encrypt.
Author
Owner

@tessus commented on GitHub (Feb 17, 2019):

I believe this project is pretty much dead. @Econa77 doesn't reply to questions and suggestions.

Some things just don't work on Mojave and no fixes are available. It's a shame, but it seems it follows the same fate as ClipMenu.

I'm still using it, but I have serious problems on Mojave and I'm looking for a replacement. Unfortunately I haven't found one yet.

My only hope is that someone forks this project and starts working on it. Fingers crossed.

<!-- gh-comment-id:464501970 --> @tessus commented on GitHub (Feb 17, 2019): I believe this project is pretty much dead. @Econa77 doesn't reply to questions and suggestions. Some things just don't work on Mojave and no fixes are available. It's a shame, but it seems it follows the same fate as ClipMenu. I'm still using it, but I have serious problems on Mojave and I'm looking for a replacement. Unfortunately I haven't found one yet. My only hope is that someone forks this project and starts working on it. Fingers crossed.
Author
Owner

@amcgregor commented on GitHub (Feb 22, 2019):

Don't rely on each individual application you utilize to implement encryption or other security measures at all, let alone correctly. Utilize full-disk encryption (FileVault on macOS) with a strong password or passphrase, don't enable key escrow ("unlock with my Apple ID"), and practice digital hygiene. It's interesting that people have mentioned password managers. They're not well implemented, either.

<!-- gh-comment-id:466586571 --> @amcgregor commented on GitHub (Feb 22, 2019): Don't rely on each individual application you utilize to implement encryption or other security measures at all, let alone correctly. Utilize full-disk encryption (FileVault on macOS) with a strong password or passphrase, don't enable key escrow ("unlock with my Apple ID"), and practice digital [hygiene](https://objective-see.com). It's interesting that people have mentioned password managers. [They're not well implemented, either.]( https://www.securityevaluators.com/casestudies/password-manager-hacking/)
Author
Owner

@xdxdy commented on GitHub (Feb 25, 2019):

Don't rely on each individual application you utilize to implement encryption or other security measures at all, let alone correctly. Utilize full-disk encryption (FileVault on macOS) with a strong password or passphrase, don't enable key escrow ("unlock with my Apple ID"), and practice digital hygiene. It's interesting that people have mentioned password managers. They're not well implemented, either.

The problem is if you just store everything by plain text in the disk, every other application can easily copy it and upload it to anywhere as long as it has the basic permission to access files.

So at least, we should be able to customize the path of the data file to avoid a copy attack.

<!-- gh-comment-id:467050015 --> @xdxdy commented on GitHub (Feb 25, 2019): > Don't rely on each individual application you utilize to implement encryption or other security measures at all, let alone correctly. Utilize full-disk encryption (FileVault on macOS) with a strong password or passphrase, don't enable key escrow ("unlock with my Apple ID"), and practice digital [hygiene](https://objective-see.com). It's interesting that people have mentioned password managers. [They're not well implemented, either.](https://www.securityevaluators.com/casestudies/password-manager-hacking/) The problem is if you just store everything by plain text in the disk, every other application can easily copy it and upload it to anywhere as long as it has the basic permission to access files. So at least, we should be able to customize the path of the data file to avoid a copy attack.
Author
Owner

@yurikoles commented on GitHub (Feb 25, 2019):

I totally agree with @xdxdy, since every user app may read this file with just default read permission of this user that it inherits. So it must be considered as high-level security and privacy issue.

<!-- gh-comment-id:467110733 --> @yurikoles commented on GitHub (Feb 25, 2019): I totally agree with @xdxdy, since every user app may read this file with just default read permission of this user that it inherits. So it must be considered as high-level security and privacy issue.
Author
Owner

@yurikoles commented on GitHub (Feb 25, 2019):

One of possible approaches would be usage of some key that is stored in native macOS keychain.

<!-- gh-comment-id:467111859 --> @yurikoles commented on GitHub (Feb 25, 2019): One of possible approaches would be usage of some key that is stored in native macOS keychain.
Author
Owner

@amcgregor commented on GitHub (Mar 4, 2019):

One of possible approaches would be usage of some key that is stored in native macOS keychain.

Except that the key would need to be in application-accessible memory (unencrypted, outside keychain) in order for it to be utilized on-demand during copy and paste-specific operations. AES keys, as an example (though this also applies to RSA or (EC)DSA keys), have an easily identified "shape" to them in memory, making identification and extraction relatively simple. (Scrubbing of that "master password" memory is one of the common failures in the password manager research I linked.)

… plain text in the disk, every other application can easily copy it …

Yes. You then have Lulu or another outbound firewall solution letting you know when applications on your system try to exfiltrate data, since you can't really stop non-sandboxed applications from attempting such things. Additionally, run as little non-sandboxed software as possible.

So at least, we should be able to customize the path of the data file to avoid a copy attack.

Customizing the path is "security through obscurity" — not security at all. (A quick read of the preferences .plist file for Clipy would tell you where to look, e.g. run defaults read com.clipy-app.Clipy in a terminal. Or, lsof and see which files are open by that process, etc.)

Security through obscurity...

<!-- gh-comment-id:469346067 --> @amcgregor commented on GitHub (Mar 4, 2019): > One of possible approaches would be usage of some key that is stored in native macOS keychain. Except that the key would need to be in application-accessible memory (unencrypted, outside keychain) in order for it to be utilized on-demand during copy and paste-specific operations. AES keys, as an example (though this also applies to RSA or (EC)DSA keys), have an easily identified "shape" to them in memory, making identification and extraction relatively simple. (Scrubbing of that "master password" memory is one of the common failures in the password manager research I linked.) > … plain text in the disk, every other application can easily copy it … Yes. You then have [Lulu](https://objective-see.com/products/lulu.html) or another outbound firewall solution letting you know when applications on your system try to exfiltrate data, since you can't really stop non-sandboxed applications from attempting such things. Additionally, run as little non-sandboxed software as possible. > So at least, we should be able to customize the path of the data file to avoid a copy attack. Customizing the path is "security through obscurity" — not security at all. (A quick read of the preferences `.plist` file for Clipy would tell you where to look, e.g. run `defaults read com.clipy-app.Clipy` in a terminal. Or, `lsof` and see which files are open by that process, etc.) ![Security through obscurity...](http://f.cl.ly/items/1Y0I0J242c192w083T0D/zzinger-best-practices-morpheus.jpg)
Author
Owner

@tamsky commented on GitHub (May 7, 2019):

@tessus

My only hope is that someone forks this project and starts working on it. Fingers crossed.

https://github.com/MarkJerde/Flycut works for me -- similar featureset

<!-- gh-comment-id:490277710 --> @tamsky commented on GitHub (May 7, 2019): @tessus > My only hope is that someone forks this project and starts working on it. Fingers crossed. https://github.com/MarkJerde/Flycut works for me -- similar featureset
Author
Owner

@tessus commented on GitHub (May 7, 2019):

@tamsky thanks, but there isn't even an issue tracker. This doesn't really inspire much confidence.

Last commit was 2 years ago.

<!-- gh-comment-id:490278701 --> @tessus commented on GitHub (May 7, 2019): @tamsky thanks, but there isn't even an issue tracker. This doesn't really inspire much confidence. Last commit was 2 years ago.
Author
Owner

@amcgregor commented on GitHub (May 7, 2019):

There's also https://github.com/naotaka/ClipMenu (edited to add: 109 forks, even a few with commits ;) which formerly I used to use — the problem with useful tiny utilities is that once they work, why change them? Generally I do not look at commit history to check for aliveness. I download the app or library and see if it works. Strangely, I have not had any issues with Clipy under 10.14, beyond my unending struggle with Login Items.

<!-- gh-comment-id:490282183 --> @amcgregor commented on GitHub (May 7, 2019): There's also https://github.com/naotaka/ClipMenu (edited to add: 109 forks, even [a few with commits](https://github.com/naotaka/ClipMenu/network) ;) which formerly I used to use — the problem with useful tiny utilities is that once they work, why change them? Generally I do not look at commit history to check for aliveness. I download the app or library and see if it _works_. Strangely, I have not had _any_ issues with Clipy under 10.14, beyond my unending struggle with Login Items.
Author
Owner

@tamsky commented on GitHub (May 7, 2019):

@tessus

Last commit was 2 years ago.

His last commit was 1.4 years ago (Jan 2018) on this branch of his fork:

=)

https://github.com/TermiT/Flycut/network showed a lot of active development on his fork.
By comparison, this repo's network is very quiet: https://github.com/Clipy/Clipy/network

FWIW, Flycut works for me on Mojave. YMMV.

But I hear you; I also miss JumpCut.

<!-- gh-comment-id:490294721 --> @tamsky commented on GitHub (May 7, 2019): @tessus > Last commit was 2 years ago. His last commit was 1.4 years ago (Jan 2018) on this branch of his fork: - https://github.com/MarkJerde/Flycut/commits/UpdatesToPull =) https://github.com/TermiT/Flycut/network showed a lot of active development on his fork. By comparison, this repo's network is very quiet: https://github.com/Clipy/Clipy/network FWIW, Flycut works for me on Mojave. YMMV. But I hear you; I also miss JumpCut.
Author
Owner

@tessus commented on GitHub (May 8, 2019):

@amcgregor I used ClipMenu before Clipy. Back then naotaka abandoned the project and I think part of the code base went into Clipy. In any case, I do agree that if a SW works, there's no need to add to it.

However, Clipy does have a few problems on Mojave. e.g. you can't recover any images in the history. (copy an image to the clipboard, then another, and then some text. now try to paste the 2 images...). Usually this is not a huge problem, but when opening a bug/issue on gh or discourse, I don't want to save screenshots to my disk. I want to make several screenhots and paste them into the issue.
Maybe a bit off-topic: while I love macOS, I have serious reservations about the Objective-C API and their designers. Apple loves to take working API calls and deprecate them for no good reason, just to replace them with less advanced variations that miss half of the functionality. Thus a running program stops running after a while, because Apple is too ignorant and stupid to leave a stable API alone.

@tamsky I was looking at the master (default) branch. But I'm more concerned with the fact that I can't report any issues. But I certainly do appreciate the tip and I will check out FlyCut.

<!-- gh-comment-id:490346352 --> @tessus commented on GitHub (May 8, 2019): @amcgregor I used ClipMenu before Clipy. Back then naotaka abandoned the project and I think part of the code base went into Clipy. In any case, I do agree that if a SW works, there's no need to add to it. However, Clipy does have a few problems on Mojave. e.g. you can't recover any images in the history. (copy an image to the clipboard, then another, and then some text. now try to paste the 2 images...). Usually this is not a huge problem, but when opening a bug/issue on gh or discourse, I don't want to save screenshots to my disk. I want to make several screenhots and paste them into the issue. Maybe a bit off-topic: while I love macOS, I have serious reservations about the Objective-C API and their designers. Apple loves to take working API calls and deprecate them for no good reason, just to replace them with less advanced variations that miss half of the functionality. Thus a running program stops running after a while, because Apple is too ignorant and stupid to leave a stable API alone. @tamsky I was looking at the master (default) branch. But I'm more concerned with the fact that I can't report any issues. But I certainly do appreciate the tip and I will check out FlyCut.
Author
Owner

@padi commented on GitHub (Jun 13, 2019):

I've temporarily stopped using Clipy because of this (or any other clipboard manager for that matter).

FlyCut seems to be abandoned as well.

Maybe I'd just settle with a paid app that's at least being maintained in the App Store, to leverage Apple's app review process.

<!-- gh-comment-id:501627631 --> @padi commented on GitHub (Jun 13, 2019): I've temporarily stopped using Clipy because of this (or any other clipboard manager for that matter). FlyCut seems to be abandoned as well. Maybe I'd just settle with a paid app that's at least being maintained in the App Store, to leverage Apple's app review process.
Author
Owner

@ian4hu commented on GitHub (Aug 14, 2019):

I've temporarily stopped using Clipy because of this (or any other clipboard manager for that matter).

FlyCut seems to be abandoned as well.

Maybe I'd just settle with a paid app that's at least being maintained in the App Store, to leverage Apple's app review process.

I just maintain a fork of this at https://github.com/ian4hu/Clipy/releases

<!-- gh-comment-id:521151292 --> @ian4hu commented on GitHub (Aug 14, 2019): > I've temporarily stopped using Clipy because of this (or any other clipboard manager for that matter). > > FlyCut seems to be abandoned as well. > > Maybe I'd just settle with a paid app that's at least being maintained in the App Store, to leverage Apple's app review process. I just maintain a fork of this at [https://github.com/ian4hu/Clipy/releases](https://github.com/ian4hu/Clipy/releases)
Author
Owner

@ian4hu commented on GitHub (Aug 14, 2019):

The history contents is not encrypt.

<!-- gh-comment-id:521151438 --> @ian4hu commented on GitHub (Aug 14, 2019): The history contents is not encrypt.
Author
Owner

@amcgregor commented on GitHub (Aug 14, 2019):

Can confirm I have experienced no additional issues under 10.15 betas. The most annoying intermittent issue is that occasionally keyboard focus isn't given to the paste selection menu, I'm forced to use the mouse. As I do not copy/paste images, that issue does not impact me.

@ian4hu Thank you for sharing, even though it doesn't resolve the issue you're responding to, and the commit history's lack of any detail whatsoever would force me to review every single commit by hand before trusting the codebase… so I'll just keep using the official version, thanks. Yours has deviated by quite a bit, and if it did include encryption, that'd make me even more wary to try it out. Reference my previous comments pointing out how this request is an anti-feature, and actually protects very little.

Encrypt your machine with FDE ("Full Disk Encryption", a.k.a. "FileVault" on macOS), people, and be leery of running random software downloaded from the internet.

<!-- gh-comment-id:521208421 --> @amcgregor commented on GitHub (Aug 14, 2019): Can confirm I have experienced no additional issues under 10.15 betas. The most annoying intermittent issue is that occasionally keyboard focus isn't given to the paste selection menu, I'm forced to use the mouse. As I do not copy/paste images, that issue does not impact me. @ian4hu Thank you for sharing, even though it doesn't resolve the issue you're responding to, and the commit history's lack of any detail whatsoever would force me to review every single commit by hand before trusting the codebase… so I'll just keep using the official version, thanks. Yours has deviated by quite a bit, and if it _did_ include encryption, that'd make me even more wary to try it out. Reference my previous comments pointing out how this request is an anti-feature, and actually protects very little. Encrypt your machine with FDE ("Full Disk Encryption", a.k.a. "FileVault" on macOS), people, and be leery of running random software downloaded from the internet.
Author
Owner

@24CR commented on GitHub (Oct 26, 2021):

for those worried about using password manager: you can add applications to exclude in the history

<!-- gh-comment-id:951869014 --> @24CR commented on GitHub (Oct 26, 2021): for those worried about using password manager: you can add applications to exclude in the history
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/Clipy#186
No description provided.