Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Enforce SHA-384 signatures in Node SDK

オープン
#400 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

  • #401 @tim-kos による — マージされずにクローズ

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
65/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
node.js, typescript

調査の方向性

_calcSignature() と公開エントリーポイントの calcSignature() を見つけ、既存の署名テストと README を確認します。現在のアルゴリズム処理を確認し、追加のアルゴリズム引数に対するカバレッジを追加します。署名付きリクエストと文書化された calcSignature() の動作が一貫して sha384 を使用すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Problem

Our API keys default to sha384 signatures, but the SDK's private _calcSignature() currently accepts an algorithm argument. That makes it possible for consumers (or downstream wrappers) to generate sha1 signatures from the SDK surface, which can fail against accounts/keys configured for sha384 and causes avoidable auth failures.

Expected behavior

The SDK should consistently generate sha384 signatures for signed requests.

Proposed fix

  • Remove algorithm override support from _calcSignature() and always sign with sha384.
  • Add a regression test to ensure we keep emitting sha384 even if an extra algorithm argument is passed.
  • Document in README that calcSignature() returns sha384 signatures.

Context

This aligns SDK behavior with modern API key defaults and avoids signature-algorithm drift in downstream integrations.

主要言語
TypeScript
スター
73
フォーク
26
平均マージ
13時間 19分
マージ済み PR(30日)
32

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

transloadit/node-sdk のほかの issue

transloadit/node-sdk の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。