Skip to content

Security: garethpaul/iHeartRating

SECURITY.md

Security Policy

Supported Versions

The supported security scope for iHeartRating is the current default branch, master. Older commits, tags, branches, forks, demos, and generated artifacts are not actively supported unless the repository explicitly marks them as maintained.

Project summary: Simple Ratings View for iOS enabling you to use any image as a rating e.g. hearts, stars, pigeons etc.

Reporting a Vulnerability

Please report suspected vulnerabilities through GitHub's private vulnerability reporting or by opening a draft GitHub Security Advisory for garethpaul/iHeartRating when that option is available. If GitHub does not show a private reporting option for this repository, contact the repository owner through GitHub and avoid posting exploit details publicly until the issue can be assessed.

Do not open a public issue that includes exploit code, secrets, personal data, or detailed reproduction steps for an unpatched vulnerability.

What to Include

Helpful reports include:

  • the affected file, endpoint, permission, dependency, or workflow
  • a concise impact statement explaining what an attacker could do
  • reproduction steps using test data and accounts you control
  • the branch, commit SHA, platform version, device, runtime, or dependency versions used
  • logs, screenshots, or proof-of-concept snippets that demonstrate impact without exposing private data

Project Security Posture

  • This repository appears to be an Apple platform application or Swift sample. The active security scope is the code and documentation on the default branch.
  • Review found network clients, sockets, web APIs, or service endpoints; changes in those areas should receive security-focused review before merge.
  • Review found mobile permission or privacy-sensitive data handling; changes in those areas should receive security-focused review before merge.
  • Review found file, document, data, or media parsing flows; changes in those areas should receive security-focused review before merge.
  • No primary dependency manifest was detected in the repository root. If dependencies are added later, include a manifest and prefer reproducible installation instructions.
  • make check runs a static baseline for malformed configuration hardening, CocoaPods metadata, plist/storyboard parsing, build-script syntax, rating bounds, and rating-view edge cases when Xcode is unavailable.
  • The pinned macOS workflow uses read-only repository permissions, disables checkout credential persistence, runs the simulator XCTest suite, checks the generated Objective-C header, and builds the SampleApp without signing or package publication access.
  • Rating controls should not crash on empty image arrays, single-rating views, zero-sized images, negative minImageSize, invalid maxRating, inconsistent rating bounds, out-of-range ratings, non-editable touch endings, empty touch endings, or unexpected image assets.
  • NaN ratings must be normalized before mask calculations or integer conversion for bounce animation indexing.
  • NaN minImageSize dimensions must normalize to zero before layout geometry is calculated.
  • Infinite minImageSize dimensions must normalize to zero before layout geometry is calculated.
  • imageContentMode changes propagate to every existing image view so rendered children cannot retain stale configuration.
  • External consumers can configure the public imageContentMode property while its existing observer keeps every rating image synchronized.
  • Runtime image changes should keep image layout invalidation before mask refreshes.
  • Transformed rating views should calculate child geometry from local bounds, avoiding oversized or misaligned interactive regions.
  • Constrained rating slots should cap child widths so hostile minimum sizes cannot create overlapping interactive regions.
  • An incomplete image pair should hide full overlays and remove stale masks rather than displaying a rating without its empty-image baseline.
  • Extreme finite dimensions are bounded before multiplication or Core Animation frame assignment so malformed configuration cannot produce non-finite layout.
  • maxRating is capped before allocating paired child image views to prevent malformed configuration from causing unbounded memory growth.
  • Complete image pairs expose finite intrinsic sizing for Auto Layout; incomplete pairs expose zero intrinsic size.
  • The control exposes one adjustable accessibility element and keeps its value and traits synchronized with rating and editability changes.
  • HeartRatingView follows UIKit's main-thread-only mutation contract.

Mobile Privacy Notes

If this project requests device permissions such as location, camera, microphone, contacts, Bluetooth, health data, or local storage access, reports should describe the permission involved and whether sensitive data can be accessed, persisted, or transmitted unexpectedly. Please avoid testing against real third-party user data or accounts you do not control.

Dependency and Supply Chain Security

Dependency updates should come from trusted package managers and should keep lockfiles in sync when lockfiles exist. Do not commit credentials, private keys, tokens, generated secrets, or machine-local configuration. If a vulnerability depends on a compromised package, typosquatting risk, insecure transitive dependency, or unsafe build step, include the package name, affected version, and the path through which it is used.

Safe Research Guidelines

Good-faith research is welcome when it stays within these boundaries:

  • use only accounts, devices, data, and infrastructure that you own or have explicit permission to test
  • avoid destructive actions, persistence, spam, phishing, social engineering, or denial-of-service testing
  • minimize access to personal data and stop testing immediately if private data is exposed
  • do not exfiltrate secrets or third-party data; report the minimum evidence needed to verify impact
  • keep vulnerability details confidential until the maintainer has assessed the report

Maintainer Response

The maintainer will review complete reports as availability allows, prioritize issues by exploitability and impact, and coordinate a fix or mitigation when the affected code is still maintained. For sample, archived, or educational repositories, the likely remediation may be documentation, dependency updates, or clearly marking unsupported code rather than a production-style patch release.

There aren't any published security advisories