Bugs Fixed

----------

23788: OpenSSL thread locking callback is called after all threads have been joined and cleanup has begun

24758: CompilerParser::Find_ScratchVariable_Ident can be susceptible to a buffer overflow

24759: Passing a negative value for the "-O" flag causes a segfault

24762: mvc fails to pass the verbose flag to the assembler

24817: The JSONDecoder should clear any existing data from the output parameter

26511: LOWER function leaks memory 26512: UPPER function leaks memory

26517: SQL_Stack::PopBool should use the string length, not the string size

26518: MivaSQL crashes when search condition does not contain RHS operators

26522: MivaSQL UNION should remove duplicates from individual result sets

26525: SQL_Bucket_Record does not delete the value popped off of the stack

26556: MvSMTP should clear the g.MvSMTP_Error variable on a successful connection

26572: PostgreSQL: Add prepared statement to cache after query is executed / view is closed

26602: Compiler: MvOPENVIEW should output a compiler error if the QUERY attribute is missing

26767: CommandLine_Warning_Flags has bad index boundary checks

26772: LocateDSOs should output an error when the .so/.DLL directory encounters an error

26841: UNIXReentrantFileManager::DirectoryListing should use readdir_r

26881: Generate SHA256SUMS of all distribution files and components

27000: VariableHash::LookupVariable_Fancy on present but uncreated variable causes a crash

27031: DefaultDatabaseVariable::Clone is cloning the wrong variable

27037: SpecialVariables values are not set to the parent's value in a multi-threaded environment

New Builtin Functions

---------------------

- file_set_time( path, location, modified )

Sets the file's modified time

Parameters:

- path - The path to the file

- location - Either script or data

- modified - time_t (seconds since 1-JAN-1970)

Return Value: - 1 on success, 0 on failure

- crypto_next_error()

Gets the next crypto error

Parameters:

- None

Return Value: - The appropriate crypto error

- crypto_clear_error()

Will clear out all crypto errors

Parameters:

- None

Return Value:

- Empty

- crypto_evp_sign( digestname, privkey, buffer, signature var )

Generates an RSA / ECDSA signature

Parameters:

- digestname - Hash algorithm name, such as "md5" or "sha256". Supported digest algorithms will vary between OpenSSL installations

- privkey - EVP PKEY structure reference

- buffer - The data to sign

- signature - The signed output signature

Return Value:

- 1 on success, 0 on failure

- crypto_evp_verify( digestname, pubkey, buffer, signature )

Verifies an RSA / ECDSA signature

Parameters:

- digestname - Hash algorithm name, such as "md5" or "sha256". Supported digest algorithms will vary between OpenSSL installations

- pubkey - EVP PKEY structure reference

- buffer - The data to verify

- signature - The signature to verify

Return Value:

- 1 on success, 0 on failure

- evp_pkey_load_pubkey_x509( x509 var, pkey var )

Loads a PKEY reference from an x509 public key reference

Parameters:

- x509 - Certificate reference returned from functions such as x509_load_mem

- pkey - Structure reference

Return Value:

- 1 on success, 0 on failure

Other

-----

- crypto_last_error

Previously if the crypto error originated from Miva Empresa, the returned error was always the same. If the crypto error was from OpenSSL then it would be lost after calling the function. Modified to always return the last crypto error.

- trim / ltrim / rtrim

Will now trim whitespace from arrays and structures. Previously the functions would convert arrays and structures to serialized data and then trim it. Arrays and structures are now iterated and all values within are trimmed appropriately.

- POST content type of "application/json" is now supported. The POSTed data will be parsed and stored in the s.json_data variable as a JSON object. The raw POSTed data will populate the s.content_data variable.

- Added the FLAGS attribute to MvCALL / mvt:call. The only supported flag currently is "noparse" which will disable parsing of the returned data. The data will populate the s.callvalue variable. This is ideal if you do not need to iterate HTML / XML elements.

- evp_pkey_load_mem now supports the DER and PEM formats.

- Added support for Redis. The use of the redis functions can be obtained by adding a system library with the code of "hiredis."

- The compiler now warns when text / HTML is present and will not be output in the current context

Miva Merchant 9.11.00 Release Notes

Other Changes

This patch enables browser verification for all administrative users.

THIS IS A SECURITY RELEASE AND PER PCI-DSS REQUIREMENTS YOU MUST UPGRADE WITHIN 30 DAYS

Miva Merchant 9.10.01 Release Notes

Bugs Fixed

26925: Administrative Interface: Image_FindOrInsert_RenameFile_NoDuplicates needs to determine the image type before determining the image dimensions

26932: Administrative Interface: Rich text editor does not function when the Administrative interface is protected by HTTP authentication

THIS IS A SECURITY RELEASE AND PER PCI-DSS REQUIREMENTS YOU MUST UPGRADE WITHIN 30 DAYS

New Features

Browser Verification

• When logging in from a new device/browser, a verification code will be emailed to the user. The user must enter this code to authenticate the browser they are using.

Default Groups

• New default groups have been created to make things easier for users.

Two-Factor Authentication

• Administrators and users with a developer license are now required to enable two-factor authentication. When logging in, if they do not have two-factor enabled, they will be directed to a new screen that forces them to enable two-factor authentication.

• Administrator users will have the option to reduce their privileges instead of enabling two-factor.

• Additional two-factor methods:

• YubiCloud

• WebAuthn/U2F support

• Backup tokens

Other Changes

User/Group Improvements

• Groups are now managed at the domain level instead of in each individual store.

• The Add Userdialog has been modified to make it easier to create non-administrator users.

• It is now (deliberately) more difficult to create an administrator user. Two-factor authentication must be enabled in order to give a user the administrator privilege.

• Removed the "create other users" privilege

Time-based One-time Password

• TOTP settings are now configurable only through provisioning

• Two-factor codes are now collected on a separate screen

• Domain-level two-factor enablement flag has been removed • User email and cellphone fields have been added

Subresource Integrity

• Output integrity and crossorigin attributes for all JavaScript in admin and many JavaScript files in clientside

Bugs Fixed

25202: Setup Script: Remove remove.mvc from distributions

26415: Module: customfields: Module: Custom Fields: Read_Product_ID/Code functions should support multi-text fields

26527: Module: customfields: Custom Fields: Add / edit product screen: Multi-text custom fields values are not saved between tab switches

26549: Core JSON: JSON_Image_Upload does not log successful uploads to the admin activity log

26550: Core JSON: JSON_ProductImage_Upload does not log successful uploads to the admin activity log

26551: Core JSON: JSON_Framework_Upload does not log successful uploads to the admin activity log

26552: Customers: Customers: Shipping / Billing Information screen is susceptible to stored cross site scripting

26553: Digital Downloads: Product: Digital Download Settings screen is susceptible to stored cross site scripting

26554: Administrative Interface: Forced Password Changes are not being logged in the admin activity log

26555: Module: stdschtasks: Module: Standard Scheduled Tasks: Add / edit scheduled task screen is susceptible to stored cross site scripting

26570: Customers: Customers: Address Add / Edit Dialog is susceptible to stored cross site scripting

26608: Administrative Interface: Upload of Digital Download files should check for the DDLS modify permission

26610: Digital Downloads: Digital Downloads: The upload button on the edit product screen should only show when the user has the DDLS modify privilege

26743: Module: ptbship: Editing a table to show a redundant ceiling does not display error

26744: Module: wtbship: Editing a table to show a redundant ceiling does not display error

26745: Module: canvat: Incorrect sorting on the Canadian VAT tab

26746: MMBatchList: MMBatchList: Record_Changed should take item as a parameter in order to determine the correct column

26779: Core JSON: JSON_ModuleList_Load_Query should not error when Module_Load_Features has no results

26878: Administrative Interface: License validation error screens have unencoded outputs

Docs

Two Factor Authentication - https://docs.miva.com/how-to-guides/two-factor-authentication

Browser Verification - https://docs.miva.com/how-to-guides/browser-verification

User Groups - https://docs.miva.com/how-to-guides/user-groups

HTTPS has always been a core part of any ecommerce website. If you’re accepting personal information online, including credit cards, you must have an SSL Certificate to encrypt the data. Typically, a website was only served over securely (HTTPS) on Account and Checkout Pages. General shopping and browsing was done over unencrypted HTTP. Over the past couple of years, that is starting to change. Google now prefers the entire site to be served over HTTPS to protect the visitor. They are even giving sites that are all https a small ranking boost. 

While serving every page over HTTPS adds some additional server overhead and can cause the page to load slightly slower, the additional time should be unnoticeable to the visitor.

This tutorial will walk you through step by step how to convert your Miva store to be entirely served over HTTPS. While the actual implementation and changes are relatively simple, making sure everything is done correctly is extremely important. If done improperly there are negative customer experiences which can occur, such as getting insecure warnings on pages and negative SEO consequences which can damage your rankings – both of which you want to avoid.

Click here to read more

As Miva has evolved, we’ve built a unique, hybrid Software-as-a-Service (SaaS) platform that allows our customers to retain the control and independence of distributed software, while having the easy upgrades we’ve all come to expect from SaaS platforms. It’s time we refine and formalize our policies on when software is officially EOL (End of Life), and update our Non-Compliance Fee (NCF) policies accordingly.

Most Software-as-a-Service platforms don’t give you a choice when it comes to upgrades – you simply login one day and your platform has been upgraded for you, whether you like it or not, and whether it negatively impacts your business or not.

Miva has chosen a different path. While providing the type of seamless upgrades and updates people have come to expect from Software-as-a-Service, we don’t force you to upgrade before you’re ready. The downside to this path is that, often times, people will choose to run out-of-date software; and in this day and age, it’s simply not a wise, safe or prudent choice to run out-of-date software. 

We specifically created and use the Non-Compliance Fee program as an economic incentive program to encourage people to update their stores regularly.

For example, in my opinion, it is simply not safe to run any version of Miva Merchant prior to 5.5 Production Release 8 Update 7 (which was released on October 16, 2012, over two and a half years ago), yet we still have many customers who choose to run Miva Merchant 5.5 PR8 Update 6 or older (including people still running 2.x stores, which was released way back in 1999).

Going forward, Miva Merchant software will be considered EOL (End of Life) when either of these 2 circumstances are met:

1. Software has been officially Non-Compliant due to normal software releases, from the perspective of PCI software updates, for more than 12 Months. In other words, 15 months after the release of a new update, software will officially become EOL.

or 

2. Software that is Non-Compliant due to a security release, from the perspective of PCI software updates, for more than 3 months. In other words, if we mark an update as a security-focused update, per the terms of PCI compliance, older software will be considered EOL 4 months after the security update is released.

What impact does Miva marking a product as End of Life have on you, the merchant?

First and foremost, it means we will not, under any circumstances, release a patch, update or upgrade for that version. The most common use cases would be either an API change by a provider (say for example USPS changes its rating API, we will not be releasing an updated USPS module to work on any EOL version of Miva Merchant).

Second, when there are system-level security changes (such as POODLE in 2014), we will not be releasing a patch or engine upgrade to keep EOL software fully operational on modern Operating Systems.

Non-Compliance Fee program changes:

Currently, we have a varied Non-Compliance Fee program that means you pay a different fee depending on if you’re hosted by a third party or directly with us; and, if you’re hosted with us, your fee varies based on the plan you have.

Going forward, we’re standardizing our Non-Compliance Fee program to a flat rate program. Your NCF will be $50 per month, if you’re running Non-Compliant but non-EOL’d software; or, it will be $100 per month, if you’re running Non-Compliant and EOL’d software.

Click here for the original blog post.

For anyone looking to build ReadyThemes (or you just want to learn more about how the new ReadyThemes works) We just released 5 new developer videos which walk through the Base Developer Framework as well as a overview of the main ReadyTheme features and functionality

http://www.miva.com/videos/category/readythemes


We'll be continuing to add new ReadyTheme videos however, if you have any areas you would like to see more video content (or written documentation) on let me know and I can add it to our queue.

Some other helpful links:

ReadyTheme Documentation - https://docs.miva.com/videos/articles/...-documentation

Base ReadyTheme Framework - https://docs.miva.com/videos/articles/...ase-readytheme

Dear Miva Merchant 4.x Customers,

As many of you already know, July 1, 2010 was the mandatory deadline for all payment applications to become PA-DSS Validated. This requirement impacts all payment gateway providers, swipe terminals, and shopping cart vendors like Miva Merchant.

PA-DSS Validation is different from PCI-DSS Compliance. Both are implemented and governed by the PCI Security Council, but in order to maintain your PCI-DSS Compliance as a merchant, you must be running PA-DSS Validated (and properly configured) software.

Miva Merchant recently completed its PA-DSS Audit and has received its Attestation of Validation (AOV) for Miva Merchant 5.5 Production Release 7. However, Miva Merchant 4.x is not and will not be PA-DSS Validated.

There are a number of reasons why we’ve been unable to validate Miva Merchant 4.x. The bottom line is that due to the complexity of the software code, it would be impossible to maintain compatibility with existing 4.x stores while still achieving validation.

So here is what we are providing for you, our valued Miva Merchant 4.x customers, to enable you to be fully PA-DSS Validated: an absolutely FREE (yes free) upgrade license to Miva Merchant 5.5. This upgrade license previously cost $399. But it is now available free of charge to every Miva Merchant 4.x user with an eligible license. Please contact your Host or Miva Merchant at (858) 490-2570 for information on your upgrade license.

We’ve also developed three new tools (also free) to make it easier to upgrade to 5.5.

1. OpenUI/MMUI Framework Exporter
2. Order History Exporter
3. Catalog Exporter (Products, Categories, etc...)

You can get information and to download the tools here

In addition, for any Miva Merchant 4.x storeowners whose merchant account providers are not providing a grace period for running PA-DSS Validated software, we’ve cut a deal with PayPal to provide you a reduced rate on PayFlow Link. Utilization of PayFlow Link provides a workaround that, though less than ideal, will fully integrate with Miva Merchant 4.x as it exists today and handle all of your PA-DSS and PCI-DSS requirements. Finally, you need to be aware that Miva Merchant 4.x will formally reach End Of Life on December 31st, 2011.

Until then, we will continue to maintain existing critical shipping and payment updates to ensure your 4.x store operates as it does today. But as stated above, PA-DSS Compliance will only be available through the PayFlow Link workaround. And on January 1st, 2012 all support and updates will cease for those who have not upgraded to Miva Merchant 5.5.

We want you and your store to continue to succeed. That’s why the Miva Merchant team is providing you with this free upgrade to 5.5. We encourage you to begin the upgrade process immediately in order to maintain the best experience for you and your customers – as well as robust compliance and validation with all PCI security issues.

Community Forum post regarding Miva Merchant 4.x PA-DSS Update and End Of Life Announcement

Click Here

Credit Card Security Code ( CVV2 ) explained

What is the CVV2?

The CVV2, Credit Card Security Code is the number found on the back of most cards. It's usually a three digit code, and it's purpose is to ensure that the person using the card for a purchase actually has that card IN THEIR HAND.

Why ask for the CVV2?

There are LOTS of ways that criminals can get their hands on lists of stolen credit card numbers. Getting hold of matching CVV2 numbers is much more difficult. Because of that, if your store verifies the CVV2 at checkout then it is much more likely that the purchase is genuine.

How can I accept CVV2?

Miva Merchant has modified many of its CURRENT payment gateways to include the CVV2 feature in the LATEST releases. Some CVV2 supported gateways are:
# AuthorizeNet

# Innovative Gateway
# First Data Global Gateway
# Payflow Link
# Payflow Pro
# CHASE Paymentech Orbital Gateway

# CyberSource

What if you process your orders through a terminal and it NEEDS CVV2

This is another frequently asked questions. The simple answer is... Tough Luck!.

There is a REASON why your terminal wants this CVV2. It's probably because your merchant account provider is giving you a good rate for NON-INTERNET sales. They give you this rate because if you are processing a card through a terminal, and have the card in hand then this is low risk. If on the other hand you are trying to process internet sales, then your merchant account providor wants to charge you Mid or Low qualifying rates.

What do you do? Well one thing you cannot do is find some way to store your customers CVV2 at checkout. This is absolutely forbidden by Visa, Mastercard etc. Think about it... what value is the CVV2 standard if people start storing this number with the credit card!!!

Bottom line, if you use simple credit card validation then your only options are:

# 1. Call customers and ask for the CVV2 when processing the transaction
# 2. Upgrade your payment gateway to one of the options above.