In a PGP like Application , would compress and encrypt leak information

would compress and encrypt on data comromise security for PGP like application, would it be secure for use in Encrypted Messaging?

I have heard its safe for data at rest encryption , i have heard about CRIME and BREACH attacks on TLS, i am concerned if it would affect PGP like applications and the case of encrypted messengers.

Compression before encryption can leak information in a few ways.

Compression occurs on the plaintext, encryption is on the result of compression, and then there's a public and quite precise relation between size of result of compression and size of ciphertext (including if there's also compression in the encryption, as is the case by default in GPG, an implementation of (Open)PGP). Therefore the size of the result of compression of the plaintext is known to great precision (often, exactly) to adversaries. So is the nature of the compression. And that leaks some information about the plaintext. Some examples:

• If the plaintext is known to be constant length, that tells it's compressibility, and that's an important information. In particular, for voice truncated into short constant-time frames with audio compression, as in VoIP, according to this 2008 paper that can be enough to discern some phrases! And as the saying goes, “Attacks always get better; they never get worse” (attributed to the NSA by Bruce Schneier).
• Similarly, if long text messages are broken into separate segments of mostly fixed size and they are individually compressed, it will me possible to distinguish some features of the text (like what alphabet is used, or which of two different persons wrote it, if they have different typing habits).
• For photographs, size of ciphertext is an excellent indicator of which of several images was sent, and compression kills attempts to hide this by making the images of identical size. Even if such images are sent a single time, things like if they where on focus or not, or if they are taken at day or night, are likely to leak.

When using pure encryption (e.g. a block cipher in CTR, CBC, OFB mode), adversaries can alter ciphertext, so that altered compressed data will reach the de-compressor on the receiver side. Depending on de-compressor and alteration, the de-compressor can crash (that's common, and is often enough for a so-called Denial of Service attack), abort with error which perhaps can be sensed by adversaries, or output corrupted data which perhaps can leak in part to adversaries (e.g. the length of the corrupted data might be measured by timing the behavior of the receiver). Repeating observation of the behavior of the receiver for different alterations of the ciphertext can conceivably leak more and more information on the plaintext, similar to some padding oracle attack. Feasibility depends a lot on details of the compression and of the receiver setup. Fortunately, authenticated encryption (after compression and before decompression) prevents such attacks, and is now widely available, including in modern ciphersuites of OpenPGP/GPG.

Also, compression and decompression algorithms are almost never designed to be constant-time, much less to resist other side-channel or fault attacks, and there could be some information leak. However that's true for most data-processing algorithms in common use, so this concern is general when sensitive data is manipulated, rather than specific to using compression.

Just a little clarification: PGP is mainly used for data on the move as it encrypts messages between two keys/accounts (unless you use symmetrical options which isn't really its raison d'etre).

Both CRIME and BREACH attacks focus on secrets retrieval, typically session cookies. They both require multiple autonomous server responses to small variations in attacker generated input.

That's not the modus operandi of PGP. In PGP messaging information is compressed and then encrypted once for each sender generated message. Yes, the size of the compressed message can be inferred from the encrypted .pgp file. In the case of automatic cookie transport, any attacker has a good idea of the original size, so correlated compressive attacks are possible. In the messaging situation, the attacker doesn't really know the original message size, so the .pgp file isn't all that leaky. And there's only one message, not under attacker control.

E.g. A 1,000,000 file of zeros creates a .pgp file of 1598 bytes (encrypted to a random recipient). But if you didn't know that I sent a million bytes of nothing, what could an attacker infer or what significant advantage would he obtain? Thus TLS/CRIME/BREACH attacks are inapplicable to a PGP message.