Skip to content

Commit e4ed848

Browse files
committed
Merge #531: Remove serde_keypair module
513144c Remove serde_keypair module (Tobin C. Harding) Pull request description: Done while unsuccessfully trying to solve #514 The `serde_keypair` module appears to be only used for testing, however it is part of the public API for the `key` module? serde de/serialization is already implemented on `KeyPair` by way of the normal `serde` traits, there is no obvious reason for the `serde_keypair` and the `KeyPairWrapper`. Remove the `KeyPairWrapper` and test `KeyPair` serde impls directly. ACKs for top commit: apoelstra: ACK 513144c Tree-SHA512: 23891217f3afc7cb3bb03431946e9866ee6ae611153fca8d93fe393b5a4abbd41d4713c6aa5ab24eb2734d8c8d94a9f6aed47316284b4097aa40f49f055f36b6
2 parents 5c15a49 + 513144c commit e4ed848

File tree

1 file changed

+2
-61
lines changed

1 file changed

+2
-61
lines changed

src/key.rs

+2-61
Original file line numberDiff line numberDiff line change
@@ -1530,42 +1530,6 @@ impl<'de> serde::Deserialize<'de> for XOnlyPublicKey {
15301530
}
15311531
}
15321532

1533-
/// Serde implementation for the [`KeyPair`] type.
1534-
///
1535-
/// Only the secret key part of the [`KeyPair`] is serialized using the [`SecretKey`] serde
1536-
/// implementation, meaning the public key has to be regenerated on deserialization.
1537-
///
1538-
/// **Attention:** The deserialization algorithm uses the [global context] to generate the public key
1539-
/// belonging to the secret key to form a [`KeyPair`]. The typical caveats regarding use of the
1540-
/// [global context] with secret data apply.
1541-
///
1542-
/// [`SecretKey`]: crate::SecretKey
1543-
/// [global context]: crate::SECP256K1
1544-
#[cfg(all(feature = "global-context", feature = "serde"))]
1545-
pub mod serde_keypair {
1546-
use serde::{Deserialize, Deserializer, Serialize, Serializer};
1547-
1548-
use crate::key::{KeyPair, SecretKey};
1549-
1550-
#[allow(missing_docs)]
1551-
pub fn serialize<S>(key: &KeyPair, serializer: S) -> Result<S::Ok, S::Error>
1552-
where
1553-
S: Serializer,
1554-
{
1555-
SecretKey::from_keypair(key).serialize(serializer)
1556-
}
1557-
1558-
#[allow(missing_docs)]
1559-
pub fn deserialize<'de, D>(deserializer: D) -> Result<KeyPair, D::Error>
1560-
where
1561-
D: Deserializer<'de>,
1562-
{
1563-
let secret_key = SecretKey::deserialize(deserializer)?;
1564-
1565-
Ok(KeyPair::from_secret_key(crate::SECP256K1, &secret_key))
1566-
}
1567-
}
1568-
15691533
#[cfg(test)]
15701534
#[allow(unused_imports)]
15711535
mod test {
@@ -2215,31 +2179,8 @@ mod test {
22152179
use serde::{Deserialize, Deserializer, Serialize, Serializer};
22162180
use serde_test::{assert_tokens, Configure, Token};
22172181

2218-
use super::serde_keypair;
22192182
use crate::key::KeyPair;
2220-
2221-
// Normally users would derive the serde traits, but we can't easily enable the serde macros
2222-
// here, so they are implemented manually to be able to test the behaviour.
2223-
#[derive(Debug, Copy, Clone, Eq, PartialEq)]
2224-
struct KeyPairWrapper(KeyPair);
2225-
2226-
impl<'de> Deserialize<'de> for KeyPairWrapper {
2227-
fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
2228-
where
2229-
D: Deserializer<'de>,
2230-
{
2231-
serde_keypair::deserialize(deserializer).map(KeyPairWrapper)
2232-
}
2233-
}
2234-
2235-
impl Serialize for KeyPairWrapper {
2236-
fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
2237-
where
2238-
S: Serializer,
2239-
{
2240-
serde_keypair::serialize(&self.0, serializer)
2241-
}
2242-
}
2183+
use crate::SECP256K1;
22432184

22442185
#[rustfmt::skip]
22452186
static SK_BYTES: [u8; 32] = [
@@ -2250,7 +2191,7 @@ mod test {
22502191
];
22512192
static SK_STR: &str = "01010101010101010001020304050607ffff0000ffff00006363636363636363";
22522193

2253-
let sk = KeyPairWrapper(KeyPair::from_seckey_slice(&crate::SECP256K1, &SK_BYTES).unwrap());
2194+
let sk = KeyPair::from_seckey_slice(&SECP256K1, &SK_BYTES).unwrap();
22542195
#[rustfmt::skip]
22552196
assert_tokens(&sk.compact(), &[
22562197
Token::Tuple{ len: 32 },

0 commit comments

Comments
 (0)